Two flaws, one emergency release

The PHP project shipped four emergency releases on 21 October — 8.5.12, 8.4.27, 8.3.36 and 8.2.35 — fixing two vulnerabilities that each carry a CVSS v4.0 base score of 9.2 and can allow unauthenticated remote code execution. The maintainers published an advisory alongside them telling operators to update now.

The first, CVE-2026-109618, is a memory-handling bug. PHP uses longjmp() to abandon the current context when it runs out of memory, and the advisory describes cases where request memory is reachable before it has been fully initialised. If an allocation fails at that moment, the early exit leaves that memory invalid and request shutdown may read or branch on it. The advisory says an attacker can reach the path through multipart parsing — a missing content-length header, an excess of part headers, or many empty file controls with nested field names — and that this can lead to remote code execution as the web worker account.

The second, CVE-2026-109619, is a stale-state bug: internal state owned by one request can survive after its memory is freed, so a later request handled by the same worker process may follow the dangling references.

The PHP advisory says risk is highest for mod_php but that all web-serving installations are affected, naming PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. The GitHub advisory is more precise about how far the work got: mod_php and FrankenPHP are described as the most directly susceptible, while FPM is judged susceptible from source analysis without a complete working exploit having been demonstrated.

A developer at a desk reading code in an editor on a large monitor
Illustration: PHP's maintainers led the fixes and the release. Stock photograph; the code on screen is not PHP. ThisIsEngineering · pexels · Pexels License

Where the AI comes in

OpenAI published its own account the same day. In a post about what it calls Patch the Planet, the company says the security firm Calif identified a critical flaw using GPT‑5.6 Sol, and that Wiz independently discovered and reported both vulnerabilities. PHP’s maintainers led the fixes and the release.

The credit list in the GitHub advisory matches that account: it names four reporters, including handles suffixed -wiz and -oai, and four PHP developers who built the remediation.

OpenAI’s framing is that the industry got lucky on timing. “To our knowledge, frontier AI found these vulnerabilities before attackers did,” the company writes, “opening a Defender’s Window for maintainers and security providers to prepare fixes and protections ahead of disclosure.” It calls the pair “one of the most impactful security issues in recent memory” given PHP’s reach, and says it expects findings like these to “increase sharply in the coming months.” Alongside the post it committed $1 billion in subsidised access to its Daybreak security product for organisations with limited security resources, and said it had engaged the White House’s Super Intelligence Force, the Office of the National Cyber Director and CISA before disclosure.

Cloudflare’s version is less comfortable

Cloudflare, which took part in the same coordinated response, gave the pair a name — php2shell — and published its own write-up saying every web server running PHP 5.4 or later is affected. It says it began building web application firewall rules in early October and switched them on roughly nine hours before public disclosure, with free and paid plans protected by default from 03:02 UTC on 21 October.

It also says it is seeing attack traffic against its customers, and that attackers changed their payloads to try to evade the rules, with its analysts tracking match volumes to follow the mutations. That does not contradict OpenAI’s claim that defenders found the bugs first, but it narrows the window considerably: by the morning of disclosure, someone was already trying.

Blue network cables plugged into a rack-mounted patch panel
Illustration: PHP runs on most of the web, according to W3Techs figures cited by Cloudflare. Stock photograph. Brett Sayles · pexels · Pexels License

What operators have to do

Updating is the only complete fix. The PHP advisory lists interim measures — setting memory_limit=-1 through php_admin_value rather than ini_set(), lowering post_max_size, disabling session.upload_progress, and on 8.5 setting fatal_error_backtraces=0 — and is explicit that none of them makes an installation safe. It also warns against RLIMIT_AS and RLIMIT_DATA, which can trigger the vulnerable path.

PHP 8.1 and older no longer receive upstream updates, so operators on those branches depend on a distribution backport. Linux distributions and long-term-support vendors were given patches in advance. PHP 8.2 itself reaches end of life on 31 December 2026.

Cloudflare cites W3Techs for the figure that PHP runs on almost 70% of websites. The number to watch over the next fortnight is not the severity score but the patch rate on shared hosting, where the operator applying the fix is often not the person who owns the site.