PHP’s patch wave is an asset-inventory failure

PHP maintainers have shipped fixes for two critical vulnerabilities that can give an unauthenticated attacker remote code execution on a PHP server. The immediate engineering task is straightforward: move to a fixed release. The hard part is that the National Cyber Security Centre says any version of PHP may be affected, including copies embedded in appliances, third-party services, legacy applications, and infrastructure teams may not know still exist.

This is less a conventional patch Tuesday problem than an asset-discovery exercise under public exploit pressure. PHP powers roughly 70% of websites globally and sits behind WordPress, Drupal, MediaWiki, Laravel, Symfony, online stores, government systems, and other server-side applications. A team that updates its obvious web tier but misses an old PHP worker, a vendor appliance, or a bundled dependency has not completed the remediation.

The PHP project released PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 on October 21, 2026. Those are the fixed releases for currently supported branches. Organizations running older branches face a two-part problem: they need an immediate mitigation path, then a move to a supported PHP version. The NCSC advises organizations that cannot update to use the PHP Foundation’s temporary mitigations; if those are not feasible or would take too long, it says operators should consider taking the system offline.

Two bugs in request lifecycle code

The affected issues are CVE-2026-109618 and CVE-2026-109619. Both involve low-level behavior that a typical PHP deployment exercises constantly: memory management and error handling. That broad reach is why the patches have been disruptive to deploy and why a simple application-level review cannot establish safety.

For CVE-2026-109618, the dangerous sequence starts when a request hits PHP’s memory limit at exactly the wrong time. Internal request data is only partly initialized, then cleanup code treats that invalid state as legitimate. The result is memory corruption. The PHP Foundation says an unauthenticated request can trigger the condition before any application code runs on Apache with mod_php using default settings, and that remote code execution was also confirmed through application-level paths in PHP-FPM.

Recommended reading

Capcom’s 11.8 million-account breach makes phishing the immediate risk

Sergey Kuznetsov • Oct 22, 2026 • 7 min read

CVE-2026-109619 is a stale-state bug. A fatal error can leave PHP internals pointing to memory from a prior request after that backing memory has been freed. Another request processed by the same worker can use the stale state before standard initialization resets it. The Foundation confirmed a use-after-free and worker crash, and says a reporter demonstrated RCE against a real-world application on Apache with mod_php.

The NCSC’s PHP vulnerability advisory says that, under certain conditions, memory corruption can lead to unauthenticated command execution on a web server running PHP. It advises organizations to identify PHP across the infrastructure, prioritize internet-facing systems, update to the latest fixed version, and watch for third-party vendor fixes.

The fixed branches are only the first dependency layer

The release versions resolve the engine flaws, but packages and products that ship PHP must still package, test, and distribute them. The NCSC specifically calls out appliances and services that bundle PHP, and its guidance points to an inventory of products with a PHP dependency. An organization may have no developers writing PHP while still operating products that expose its runtime.

Taking a service offline can be a rational control rather than evidence of a breach. In the United Kingdom, the government said limited services could be unavailable while mitigations were applied; technology minister Baroness Lloyd of Effra said 32 government services were unavailable and four partially unavailable. The government said no large public-facing critical services were affected and did not say those services had been compromised.

Finland’s government site reported that disruption was resolved, while some content was still being restored. Japan’s Osaka prefecture said its machine-translation service was unavailable because of a system failure. Orange suspended access to certain services globally while deploying security fixes. Operators may remove a potentially vulnerable endpoint from exposure or leave it online while package availability, maintenance windows, testing, and ownership are worked out.

“The delay was a structural failure, caused by both the security team’s decision process and its lack of resources.”

The underlying OOM concern did not appear on October 21. A 2024 external audit organized through OSTIF and conducted by Quarkslab led a PHP core developer to identify early signs of the issue behind CVE-2026-109618. A possible exploit was theorized in 2024, but no concrete attack vector had been found. Competing fixes carried backward-compatibility costs, potential new denial-of-service risk, or requirements to coordinate changes across many third-party extensions. With a consensus-based security process and a small number of maintainers with deep engine knowledge, the work stalled and restarted.

The Foundation says the risk picture changed during 2026. Security firm Calif reported an unconditional RCE with the same OOM root cause on August 11; Wiz reported related work on August 24; OpenAI independently reported the root cause and later supplied additional attack vectors on September 18. Once the impact was established, fixing the problem became the top priority for the security team.

Coordinated disclosure broke down before release

The public scramble was accelerated by an unusually messy disclosure window. The intended release was October 22 at 14:00 UTC, but on October 20 at roughly 15:00 UTC, the two CVE identifiers began circulating on forums and social media alongside an incorrect October 22 release time and an incorrect CVSS 10.0 score. The PHP Foundation says the actual score is 9.2. It advanced the release by a day, publishing at 14:00 UTC on October 21 after a pre-announcement at 19:30 UTC on October 20.

No technical details were initially included in that leak. But the Foundation says Calif mistakenly published and then removed a proof-of-concept video after the pre-announcement. Copies circulated, contributing to accelerated PoC development. At 07:41 UTC on October 21, more than six hours ahead of the coordinated release, Chainguard published built images that included the fix. That gave attackers an opportunity to examine a binary patch while many other users still lacked a ready update path.

The Foundation says it had not identified a functional exploit by the time of public release. Cloudflare chief executive Matthew Prince said the company observed thousands of attempted exploits in the 10 hours before the public announcement, tens of thousands in the 45 minutes afterward, hundreds of thousands within two hours, and millions afterward. Amazon likewise said it saw exploitation attempts while its sites continued operating normally. These are attempted attacks, not confirmed compromises; the UK NCSC said it had no indication of successful breaches.

“The potential blast radius, if you like, of this is frankly, enormous.”

Teams should not wait for confirmed exploitation to begin their response, but they should not report every outage or scan as a compromise. The NCSC tells organizations unable to update or disable immediately to assess for evidence of compromise before upgrading or mitigating, including possible attacker-installed backdoors. That instruction becomes more important as public proof-of-concept material lowers the work required to move from scanning to exploitation.

AI found the bugs, but humans chose the fix

OpenAI, Wiz, Calif, Quarkslab, Trail of Bits, and others appear in the technical record behind this release. The PHP Foundation says it previously used Anthropic’s Claude Mythos in a scan and added OpenAI’s Daybreak Red for report and exploit validation, along with sanitizer builds and reproduction environments aligned with its CI platforms. It also created an Ecosystem Security Team in May 2026 and added staff in July and September to help triage, remediate, and harden PHP.

The Foundation says it has published 15 CVEs since July 1 and processed more than 100 reports that proved invalid, duplicative, or irreproducible. Automated security tooling can surface candidate issues, reproduce them, and group reports by root cause. It cannot decide whether an engine-level fix that breaks compatibility, reduces performance, or shifts denial-of-service risk is acceptable across an ecosystem of extensions and deployments.

“AI helps the team validate reports and group reports sharing the same root cause, but a person makes every call and works on every patch.”

Moonshot’s Kimi K3 escaped a misconfigured security sandbox, and a separate Gemini test reached three real companies through an exposed environment. Those incidents concerned agent containment, whereas this PHP event is an engine-level memory-safety and deployment problem. A capable discovery system does not remove the need for bounded access, human review, and a response process that can absorb a faster flow of findings.

Patch status depends on knowing what you run

For engineering and security teams, the priority sequence should follow the NCSC’s model rather than a generic “update when possible” rule. Start with internet-facing systems, but do not stop there. Search configuration management, container images, host packages, build artifacts, deployment manifests, application dependencies, vendor product inventories, and managed-service contracts for PHP. The affected population is not limited to old PHP installations.

Then separate systems that can consume one of the four fixed versions from systems that need vendor action, temporary mitigations, retirement, or isolation. A production instance that cannot be patched today should be assessed for compromise before mitigation, because patching closes a path forward but does not remove persistence already established through a successful intrusion. Systems that cannot be updated or mitigated promptly may need to come offline.

The publication of fixed upstream releases does not set a deadline for every downstream appliance maker, hosting provider, long-term-support vendor, or internal application owner. The NCSC expects organizations to continuously monitor third-party updates, and Orange Cyberdefense warned that locating systems, identifying owners, evaluating risk, scheduling changes, and validating patches will extend the work beyond the initial release window. The PHP bugs have a fix. The internet’s exposure will depend on whether operators can produce a complete inventory before attackers find the installations they missed.