PHP RCE Vulnerabilities Traced to a 2024 Finding Whose Fix Stalled for Months

The PHP RCE vulnerabilities patched on October 21, 2026 grew from a flaw the PHP project first spotted in 2024 and then failed to fix for months. The PHP Foundation says its security team kept stalling between competing patches until AI-assisted researchers proved in August 2026 that the bug gave attackers unauthenticated remote code execution.

Two PHP RCE Vulnerabilities Sit in Code Nearly Every Request Touches

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical bugs that can let an attacker run code on a server without logging in. CVE-2026-109618 is triggered when a request hits PHP’s memory limit at the wrong moment, leaving half-built internal data that cleanup later treats as valid. CVE-2026-109619 lets internal state from one request outlive its memory, so a later request on the same worker reads freed memory. The PHP Foundation says remote code execution was demonstrated against Apache with mod_php under default settings, before any application code ran, and also confirmed on PHP-FPM through application paths. The foundation scores the flaws at 9.2 on CVSS. Both live in memory management and error handling, which is why they were hard to fix without breaking compatibility or slowing PHP down.

The Root Cause Surfaced in a 2024 Audit and Then Waited

In 2024 the Sovereign Tech Agency funded PHP’s first external security audit in years, arranged through OSTIF and carried out by Quarkslab. While fixing one of Quarkslab’s findings, a core developer contracted by the PHP Foundation found the first signs of the out-of-memory problem behind CVE-2026-109618. An exploit was theorized that year, but nobody found a concrete attack path, and other bugs with clearer impact took priority.

The security team drafted several fixes. Each carried a cost: a backward compatibility break, a new denial-of-service risk, or changes to many third-party extensions that seemed impossible to coordinate. The team made decisions by consensus, could not agree, and feared shipping the wrong option. The foundation says work on the fix stopped and restarted repeatedly over months, and it calls the delay a “structural failure” of both process and resources.

AI-Assisted Audits Turned a Theory Into a Working Exploit in August 2026

The PHP Foundation enrolled PHP in OpenAI’s Patch the Planet program, and security firm Calif began auditing PHP on July 30, 2026. On August 11, Calif researcher Ryan A reported an unconditional remote code execution with the same root cause found in 2024. OpenAI independently reported that root cause on the same day. Wiz reported further attack vectors on August 24, and OpenAI added more on September 18. TechCrunch’s Julie Bort reported that Wiz used its own security agent alongside Gemini and GPT models in its work. From August 11, the foundation says, the fix became the top priority for everyone on its security staff, eventually working weekends and around the clock.

The same tools have changed the team’s workload. The foundation says it has published 15 CVEs since July 1, 2026, and worked through more than 100 reports that proved invalid, duplicated or impossible to reproduce.

A Leak Pulled the PHP Release Forward by a Day

The coordinated disclosure held until two days before the planned release. Around 15:00 UTC on October 20, the two CVE IDs began circulating online with a wrong release time and an inflated CVSS score of 10.0. PHP moved its pre-announcement up to 19:30 UTC that evening and shifted the release from October 22 to October 21 at 14:00 UTC. The foundation says Calif then mistakenly published a proof-of-concept video, which sped up public exploit work, and that Chainguard published fixed images at 07:41 UTC on October 21, more than six hours ahead of the agreed release. BBC News reported that Finland temporarily shut down its government’s public web services and that the Wikimedia Foundation took several systems offline as a precaution.

The UK’s National Cyber Security Centre told organizations to inventory every PHP installation, prioritize internet-facing systems, apply the PHP team’s temporary mitigations if they cannot update, and consider taking a system offline if they can do neither.

Why This Matters for Engineering Leadership

Finding the PHP flaw was never the problem. The project knew about the root cause in 2024. The delay came from a decision with no good option and a team that required unanimous agreement to pick one. The foundation’s own fix is to let the security team decide by majority and to make sure a stuck fix reaches foundation leadership quickly. Any engineering organization carries the same risk in its own backlog: a known defect parked because every remedy breaks something. Leaders should keep a short list of security fixes blocked on trade-offs, put a named owner and a deadline on each, and define who breaks the tie when the team cannot. AI tools now turn a theorized exploit into a working one in weeks, so the gap between a known bug and an exploitable one is shrinking. The NCSC’s first instruction also deserves a direct answer from every team: can you list every system running PHP, including vendor appliances that bundle it, today?

FAQ