AI found two critical PHP flaws before attackers did. Your patch process now sets the defender's window

The most important line in this week’s PHP security advisory is a single sentence: “There are no complete mitigations, updating is the only safe choice.”

On October 21 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, rated 9.2 on CVSS v4.0. Under the right conditions, both allow an unauthenticated attacker to run code on the server. They live in the PHP runtime itself, so they reach every application built on it: WordPress, Drupal and Joomla sites, internal tools, customer portals, and the PHP inside vendor products nobody remembers buying.

They were found with frontier AI. That is the part of the story that will repeat.

What happened

Both flaws are triggered when a request makes PHP fail partway through, for example by hitting its memory limit or causing a fatal error, and depend on a later request reusing the same worker. PHP says every installation serving web requests is at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, with the highest risk for mod_php. Wiz, which published its research the same day, says nearly every version from PHP 5.4 onward has at least one of the issues, and reports pre-authentication exploit chains against WordPress, Drupal and Joomla.

The discovery involved several parties. According to the PHP Foundation, Calif, a security firm working under OpenAI’s Patch the Planet program, reported the root cause on August 11 using GPT-5.6 Sol, and OpenAI and Wiz reported further attack paths in the weeks that followed. Wiz says it found both flaws independently, with its Wiz Atlas agent, Gemini 4 Argon and GPT-5.6 Sol. The Foundation also writes, with unusual candor, that the root cause had first surfaced during a 2024 audit and that the fix “stalled for months” because of “a structural failure” in its decision-making and resourcing.

The window was shorter than planned

OpenAI’s framing is that frontier AI found these flaws before attackers did, opening what it calls a defender’s window. The window was real, and it closed early:

• Details began leaking around 15:00 UTC on October 20, according to the Foundation, which moved the release forward a day to 14:00 UTC on October 21.
• A container vendor published images containing the fix more than six hours before the coordinated release, which handed attackers the patch in binary form.
• Cloudflare, which deployed web application firewall rules about nine hours before disclosure, says it then observed attack traffic against its customers, with payloads being mutated to evade the rules.

The Foundation reported no functional exploits at release time, and OpenAI says it knows of no attacker who found the flaws first. Both statements were true when made. Neither is a reason to wait. Wiz’s assessment is the one to plan around: these exploit chains are complex, and frontier models “substantially reduced that barrier.”

What does not count as a fix

Updating WordPress or its plugins. The flaw is below the application. Cloudflare is explicit that updating site code or plugins does not fix it. If a hosting provider manages PHP, the provider has to update the runtime.

A WAF rule. Firewall rules from Cloudflare and others buy time, and attackers are already working around them. PHP lists interim configuration changes for teams that cannot update immediately, and says plainly that they reduce exposure without making an installation safe.

An unsupported version. PHP 8.1 and older receive no official fixes. The PHP security team published minimal source backports for 7.4, 8.0 and 8.1 for teams that build from source, and some Linux distributions backport fixes, but the default answer for those systems is an upgrade. PHP 8.2 reaches end of life on December 31, 2026.

What to do today

1. Find every PHP runtime, not every website. The inventory that matters is runtimes: servers, containers, base images, hosted platforms and appliances. Marketing sites and old intranet tools are the usual blind spots.
2. Patch internet-facing systems first. Prioritize by exposure, then by what the system can reach once compromised.
3. Rebuild images, do not just patch hosts. A container built last month from an unpatched base image is still vulnerable after the host is updated.
4. Ask your providers in writing. Hosting companies, SaaS vendors and appliance makers that run PHP should confirm the version they now run and when they updated.
5. Look for signs of attempts. Wiz lists unusual multipart requests followed by memory-limit errors, repeated HTTP 500 responses, malformed PHPSESSID cookies and unexplained worker churn. Application logs may show little, because the bugs run below the application.

OpenAI published a PHP version checker as a Codex skill to help identify exposed versions. It is a convenience. The authoritative list of fixed versions is PHP’s.

Why this will happen again

OpenAI writes that these bugs “are among several significant vulnerabilities we’ve already found and are working to fix,” and that it expects similar findings “to increase sharply in the coming months.” Take that literally. When AI makes finding and weaponizing flaws in old, widely used code cheaper, the bottleneck moves to the defenders’ side: volunteer maintainers, as PHP’s own account shows, and every organization’s patch pipeline.

We have argued that verification capacity, not generation, sets the pace of AI in production. Security now has the same shape: discovery is accelerating, and the slow step is confirming, fixing and deploying. And patch processes built for monthly cycles are one more example of systems sized for human tempo. The question for every security leader after this week is not whether the team can patch PHP. It is how many days the next emergency patch for a foundational runtime takes, end to end, and who owns making that number smaller.