On October 21, 2026, the PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical flaws that can let an unauthenticated remote attacker execute code as the web worker account. Wiz Research, which found them with Calif and OpenAI and calls the combined work “PHP2Shell”, says it built working exploits against the latest WordPress, Drupal and Joomla container images. As of October 22 we found no attribution to a threat actor and no report of exploitation in the wild in the PHP advisories, php.net, oss-security, Wiz or the CISA KEV feed.
What Happened
The PHP security team published two advisories on October 21: CVE-2026-109618 (“RCE via OOM corruption”) and CVE-2026-109619 (“RCE via stale global state”). Both carry a CVSS v4.0 score of 9.2 from the PHP security team (a secondary, CNA-supplied score). NVD’s own primary v3.1 score for both is 9.8 (AV:N/AC:L/PR:N/UI:N). The advisories list the 8.2, 8.3, 8.4 and 8.5 branches as affected, with fixes in 8.2.35, 8.3.36, 8.4.27 and 8.5.12. NVD’s 8.2 CPE entry has no lower bound. Both advisories rate attack complexity as high (AC:H, AT:P in the v4.0 vector), which fits the advisory’s warning that reliability varies by deployment.
Both are memory-safety bugs in how PHP behaves when a request fails part-way through. In CVE-2026-109618, PHP abandons a request with longjmp() when memory runs out; if request memory is only partly initialized at that point, shutdown can later read or branch on invalid state. The PHP advisory says multipart parsing can push a request into an out-of-memory condition while staying inside apparent limits. In CVE-2026-109619, worker processes keep global state that can point at memory from a previous request; once that memory is freed, a later request can trigger a use-after-free before normal initialization.
What the researchers and the PHP team demonstrated differs by deployment:
- Apache mod_php: the PHP advisory says unauthenticated RCE over HTTP was validated for CVE-2026-109618 with default PHP input and memory limits, in prefork configurations. The fatal-backtrace and session paths of CVE-2026-109619 were also confirmed here.
- PHP-FPM: no complete exploit for CVE-2026-109618, though source analysis suggests susceptibility. The session-lifecycle path of CVE-2026-109619 was validated, and the advisory says it depends on a suitable application operation.
- FrankenPHP and LSAPI: For CVE-2026-109618, FrankenPHP is likely susceptible by source analysis and LSAPI likely but unvalidated. For CVE-2026-109619, LSAPI is a conditional candidate and FrankenPHP’s early consumer was not established, which does not make it immune. PHP.net says risk covers all PHP installations serving web requests, and is highest for mod_php.
The advisory warns that reliability depends on the build, extensions, frontend and allocator layout, and that an exploit may need a producing request and a consuming request to reach the same worker.
Why It Matters
From an attacker’s point of view, these bugs are attractive for three reasons that come straight from the advisories and Wiz’s write-up. They need no authentication and no victim interaction. They sit in the runtime rather than in any one application, so a patched CMS on an unpatched PHP is still exposed. And Wiz says it also demonstrated application-agnostic remote memory disclosure that could expose passwords, tokens and API keys from other requests.
Wiz says “every PHP version released in the last decade is affected by at least one of these vulnerabilities”, going back to 5.4, while the PHP advisories list only the 8.2 to 8.5 branches. PHP.net says 8.1 and older no longer receive official updates, but that the security team provided minimal source backports for 7.4, 8.0 and 8.1, and that some distributions and LTS vendors ship backported fixes. Operators of older branches should check those routes rather than assume safety.
On exploitation status: we found no report of attacks in the wild in the PHP advisories, PHP.net, oss-security or Wiz. The CISA coordinator SSVC entry in NVD, stamped 14:34 UTC on October 21, lists exploitation as “none” and automatable as “no”. Neither CVE was in the CISA KEV feed as of its October 21 14:04 UTC release, which predates the CVE publication, so KEV status should be rechecked. Wiz mentions a combined exploit script called php2shell but does not say whether it is public. That window is typically short after coordinated disclosure; this is our assessment, not a claim from any source.
One unconfirmed claim is circulating: an oss-security thread relayed Fediverse posts saying the 8.5.12 fix “may be incomplete”. The thread quotes no technical detail, one of the posters said it seems a different vulnerability, and a third-hand report, relayed via a Matrix chat, reportedly has PHP calling it unrelated. As of 09:23 UTC on October 22 we found no PHP team reply on the oss-security thread (day indexes for 21–22 October checked). Treat the claim as unverified.
Wiz also says it found the bugs using Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol, and that a single researcher “completed in a week what previously would have taken a world-class team months of work”. These are Wiz’s own claims, which we have not independently verified.
Recommended Actions
- Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or later on the same branch), and restart all workers, since the bugs live in long-running worker state. Rebuild container images rather than patching running ones.
- If you cannot upgrade immediately, the advisories list partial measures:
fatal_error_backtraces=0on PHP 8.5;session.upload_progress.enabled=0;memory_limit=-1enforced administratively for CVE-2026-109618 (anmmap()failure can still triggerlongjmp()); a conservativepost_max_size; and blocking multipart requests at the edge if unused. The advisories state none of these is complete. AvoidRLIMIT_ASandRLIMIT_DATA, which trigger the vulnerable path. - Check your CDN or WAF provider. Wiz says Cloudflare, AWS, Akamai, Fastly, Google, Imperva, Microsoft and Vercel, among others, helped prepare mitigations. Confirm what is actually deployed for your account.
- Hunt for indicators, as suggested by Wiz: unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, unusually large or malformed
PHPSESSIDcookies, and unexplained PHP worker churn. The PHP advisory notes that clean logs do not prove safety. - Prioritise internet-facing mod_php hosts first, where exploitation is best demonstrated.