PHP Patches Two Critical RCEs That AI-Assisted Researchers Turned Into Working Exploits -- After a Root Cause First Spotted in 2024 Stalled, and an Embargo That Leaked a Day Early

On October 21, 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing two vulnerabilities that "can allow unauthenticated remote code execution". Its advisory names every installation serving web requests as at risk, "including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed", and rates the risk highest for mod_php, "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs."

The two bugs

• CVE-2026-109618, RCE via OOM corruption: "out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid."
• CVE-2026-109619, RCE via stale global state: "request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it."

Both sit in memory management and error handling, which nearly every request touches. Wiz's write-up, which calls the chain PHP2Shell and says PHP powers 70% of websites, describes four exploitable instances grouped under the two CVEs. They include a session upload-progress path that can leak worker memory into a PHPSESSID cookie "even when the application never calls session_start()", and an OPcache type confusion across workers. Wiz demonstrated pre-authentication RCE against the stock WordPress, Drupal and Joomla container images. The PHP Foundation gives the real CVSS score as 9.2; a circulating 10.0 was wrong.

What AI changed, and what it did not

Three parties report finding the problem with model help. The Foundation says researcher Ryan A at Calif reported "an unconditional remote code execution" on August 11 during an audit under OpenAI's Patch the Planet programme, OpenAI independently reported the same root cause that day, and Wiz reported on August 24. Wiz credits Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol, and says "a single researcher completed in a week what previously would have taken a world-class team months of work." The Foundation's own history is the necessary correction. A contractor found "the first signs of the OOM problem" in 2024 while fixing an issue from a Quarkslab audit. Competing fixes each carried compatibility, denial-of-service or extension-breakage costs, and the security team's consensus process caused work on a fix "to stall and restart repeatedly over months". The Foundation calls that delay "a structural failure". The models did not discover a hidden flaw so much as make its exploitability impossible to set aside.

A disclosure plan under strain

According to the Foundation, the CVE IDs began circulating on October 20 at about 15:00 UTC, so PHP moved the release forward a day. Calif then "mistakenly published a video" of its proof of concept, and the Foundation says that "On October 21st at 07:41 UTC, more than six hours before the coordinated release, Chainguard unilaterally broke the embargo and published built images containing the fix." OpenAI's same-day post proposes a five-stage framework for responses like this one: validating the fix, advance notice to selected distributors and providers, engagement with government agencies, wider update preparation and public guidance. It says "we expect similar findings to increase sharply in the coming months." The Foundation reports 15 CVEs since July 1 and more than 100 invalid, duplicate or non-reproducible reports.

What remains uncertain. No source reports exploitation in the wild at release. The advisory's interim mitigations, such as session.upload_progress.enabled=0 and lower post_max_size, block known paths, not every variant. Wiz and the Foundation give different accounts of when PHP prioritised the fix.

Analysis: The lesson for engineering leaders is not that AI finds old bugs. A known, unglamorous design debt became a two-day emergency once the cost of building an exploit fell, so the queue of "theoretical" issues needs re-scoring now. The binding constraint was maintainer decision-making and distributor coordination, not discovery, and money and process fix that, not more scanners. Operators should patch, then treat PHP workers that hit memory limits or churn unusually as signals worth logging.