Two critical PHP vulnerabilities have been uncovered through a coordinated security research effort involving OpenAI's Patch the Planet initiative. According to OpenAI, Calif originally discovered and coordinated the disclosure of the vulnerabilities, with Wiz independently discovering the same issues several weeks later.

Over the following two months, PHP maintainers led a coordinated disclosure and remediation effort, with OpenAI, Wiz, Cloudflare, and other industry partners contributing research, technical support, and coordination.

On October 21, 2026, the PHP project released fixes for two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Both carry a Common Vulnerability Scoring System (CVSS) v4 score of 9.2 and can allow unauthenticated remote code execution (RCE), giving an attacker the ability to run code on an affected server.

These flaws affect the PHP runtime itself, rather than a specific application, content management system, or plugin. One involves corruption during out-of-memory handling; the other involves internal state that remains accessible after the memory behind it has been freed. Their exploitation paths differ, but both require attention to the underlying runtime.

For organizations running affected PHP versions, the priority is applying the runtime fixes. PHP’s maintainers warn that temporary mitigations can reduce exposure to particular attack paths, but only an update provides a complete solution.

Why These Vulnerabilities Stand Out

Application security controls may not get a chance to act. PHP documents an unauthenticated attack path against Apache mod_php that triggers before application code runs. Application-level authentication does not protect that path.
Exposure spans different hosting environments. PHP’s advisory covers installations serving web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. Organizations need to assess the runtime, not just the application it supports.
The exploitation conditions are not identical. The demonstrated stale-state vulnerability involves different requests handled by the same worker. It would be inaccurate to describe both vulnerabilities as universally exploitable through a single request.

These distinctions matter when assessing exposure. They should inform your response, not become a reason to postpone patching.

How We Are Responding at HackerOne

At HackerOne, we are responding on two fronts: addressing PHP runtimes we operate or depend on, and preparing our vulnerability disclosure workflows to help customers identify and act on relevant findings. As we anticipate an uptick in vulnerability submissions, coordinated disclosure and effective review are central to that response.

Our security and engineering teams are actively tracking the disclosure. Where we operate PHP runtimes directly, we are applying the upstream fixes. Where we rely on managed providers, we have engaged them to confirm their patch status.

We will continue reviewing information from PHP’s maintainers, providers, and the security research community as additional technical details become available.

Alongside that work, we are preparing to help customers manage reports associated with this disclosure. Our focus is on getting relevant findings to reviewers quickly, while preserving the validation needed to distinguish a potentially exposed asset from a confirmed security issue.

How Security Researchers Are Helping Organizations Respond

Security researchers play an important role in coordinated disclosure, helping identify potentially vulnerable assets and providing findings that organizations can use to assess and prioritize risk. As vulnerability submissions increase, organizations should focus on turning those reports into actionable intelligence.

Here's what security teams should prioritize:

Strengthen your vulnerability disclosure process. Closely monitor incoming reports and use automation to deduplicate, validate, and prioritize findings based on asset criticality and demonstrated impact. Not all remote code execution vulnerabilities carry the same risk in every environment.
Use researcher findings to inform patching priorities. Apply patches as quickly as possible, but when resources are constrained, externally reported vulnerabilities specific to your environment can help identify the most urgent exposures.
Look beyond the initial patching window. Large enterprises may have overlooked PHP installations that remain vulnerable after the first round of remediation. Once initial patching is complete, consider incentivizing researchers through existing bug bounty programs to identify remaining exposures.

More submissions do not necessarily mean more successful attacks. Each finding requires validation to distinguish potentially vulnerable assets from confirmed security issues.

HackerOne is tracking relevant submission activity through Hacktivity, providing additional visibility as the coordinated response continues.

Coordinated Disclosure: From Discovery to Protection

The response to these PHP vulnerabilities also illustrates why coordinated disclosure matters. Discovering a critical flaw is only the beginning. Researchers, software maintainers, infrastructure providers, and affected organizations must work together to validate findings, develop fixes, and prepare protections before vulnerabilities are publicly disclosed.

That collaboration is particularly important for open-source software like PHP, which supports applications and services used by organizations worldwide. As AI accelerates vulnerability discovery, the ability to coordinate an effective response becomes increasingly critical.

Patch the Planet reflects this collaborative approach, bringing together security researchers, AI companies, maintainers, and industry partners to help strengthen widely used open-source infrastructure.

HackerOne is a participant in Patch the Planet, supporting the broader mission of turning vulnerability discoveries into actionable fixes through coordinated security research and disclosure.

The lesson extends beyond these two PHP vulnerabilities: Finding security weaknesses faster is valuable, but protecting organizations depends on how effectively the security community can turn those discoveries into fixes.

Guidance for Security Researchers

Researchers who have evidence of either PHP vulnerability affecting an explicitly in-scope asset should submit their findings through the relevant HackerOne program.

Reference CVE-2026-109618 or CVE-2026-109619 in the report title and body to help reviewers identify the issue. Clearly identify the affected asset, explain the demonstrated impact, and provide the evidence needed to validate the finding.

Follow the program’s testing and disclosure requirements. Keep sensitive evidence in the private report, avoid including third-party personal information, and coordinate any public disclosure through the applicable process. A public upstream advisory does not remove the need to follow a program’s rules when reporting an affected asset.

Immediate Actions for Organizations Running PHP

Identify the runtimes you depend on. Include directly managed infrastructure, hosted applications, partner-hosted properties, and appliances that bundle PHP. Establish who is responsible for patching each environment.
Apply the fixed release for your PHP branch. The patched versions are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. For packaged or managed deployments, confirm whether your provider has applied an equivalent security fix.
Do not overlook older installations. PHP 8.1 and earlier no longer receive regular upstream updates. Some vendors offer backported fixes, and PHP’s security team has supplied minimal source backports for versions 7.4, 8.0, and 8.1. Verify your vendor’s coverage or move to a supported release.
Treat interim measures as temporary. Follow the official PHP security advisory for applicable mitigation guidance while arranging the update. PHP explicitly warns that these measures do not make an affected installation safe.
Keep your reporting channels clear. Review your program scope and reporting instructions so researchers know where to submit relevant findings and your team knows how to prioritize them.

The Lesson Beyond This Release

This disclosure brings together four responsibilities: understanding the vulnerability, addressing your own exposure, making sense of incoming findings, and coordinating a response.

Our approach at HackerOne is to treat those responsibilities as connected. Remediation addresses the underlying risk. Report review helps identify findings that need attention. Coordinated disclosure gives researchers and organizations a structured way to work toward resolution.

Beyond patching, organizations should ensure they have a strong coordinated disclosure process in place so security researchers can report vulnerabilities and teams can quickly validate and act on findings. H1 Response can help organizations manage that process.

The immediate priority is to apply the PHP fixes. The broader priority is to ensure that relevant findings reach the people who can act on them.

We will update this post as the situation evolves.