TL;DR

PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 at 14:00 UTC on 2026-10-21 for two critical bugs, CVE-2026-109618 (out-of-memory corruption) and CVE-2026-109619 (stale global state after a freed request), both CVSS 4.0 9.2, both reachable by an unauthenticated HTTP request before any application code runs on Apache mod_php, and both found with AI assistance by Calif, OpenAI Codex Security and Wiz, who call the pair PHP2Shell. The PHP Foundation says the CVE ids leaked on 10-20, Calif mistakenly posted a proof-of-concept video that evening, and Chainguard published built images containing the fix at 07:41 UTC on 10-21, six hours before the coordinated release; Chainguard's CEO says it did so after public proofs and exploitation reports and does not dispute the timeline. Amazon's honeypots saw an exploitation attempt on 2026-10-17, four days before disclosure, and Cloudflare, watchTowr, Hadrian and Patchstack saw attempts before and within minutes after the release; Cloudflare's CEO reported millions of attempts by 10-22. CISA says to take unpatched PHP offline if you cannot update, including PHP 8.1 and older. Updating is the only complete fix; the vendor's interim settings reduce exposure and "do not make an installation safe."

What happened

The bugs. PHP's advisory of 2026-10-21 and the two GHSAs describe the mechanisms. CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): PHP exits an out-of-memory condition with longjmp(), and in some contexts request memory is reachable before it is fully initialised, so a failed allocation leaves request state invalid and the shutdown procedure reads or branches on it; multipart parsing gives several ways to reach OOM within apparent limits. The reporters validated full RCE over HTTP against mod_php with default input and memory limits; PHP-FPM is "susceptible by source analysis" with no complete exploit shown, FrankenPHP likely susceptible, LSAPI likely by analogy. CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): a persistent worker keeps error, session, object and extension state pointing at a previous request's freed heap, and operations that run before normal request initialisation read or free it; confirmed producers are PHP 8.5's fatal_error_backtraces (the basis of the confirmed mod_php RCE) and the session upload-progress lifecycle (validated on mod_php and FPM). Both records are the PHP CNA, both 9.2 (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H), reporters lcfr-hax, sagitzadik-wiz, tomash-areion and amyb-oai, remediation by arnaud-lb, iluuu1994, bukka and ndossche. The leaked claim of a 10.0 was never PHP's rating.

How they were found. The PHP Foundation's post: a 2024 external audit (Quarkslab, OSTIF, funded by the Sovereign Tech Agency) surfaced the first signs of the OOM problem with no concrete vector; on 2026-08-11 Ryan A of Calif reported an unconditional RCE with that root cause under OpenAI's Patch the Planet program, and OpenAI independently reported the same root cause the same day; Wiz reported attack vectors on 08-24 and OpenAI more on 09-18. The Hacker News quotes the researchers that AI models helped turn the flaws into working exploits in about a week per researcher, and Calif's caveat that the models did not start from the obscure primitives on their own. Chainguard's CEO Dan Lorenc told The Register that a researcher tipped the company on 10-16 and that its own AI tooling independently found the same bugs that night from a basic prompt.

The disclosure. The Foundation's timeline (UTC): CVE ids circulating with a wrong release time and a 10.0 score from about 15:00 on 10-20; PHP's pre-announcement at 19:30 that evening, with the release moved from 10-22 to 10-21; Calif's proof-of-concept video around 20:00; mitigation advice to some critical-infrastructure providers from 23:00, which "may also have leaked"; Chainguard's built images at 07:41 on 10-21; the coordinated release at 14:00. The Foundation says Chainguard "unilaterally broke the embargo" and let attackers study the fix in binary form. Lorenc, per The Register, says Chainguard decided on the night of 10-20, after public proofs and exploitation reports, to ship, notified PHP's coordinated-disclosure channel, made the artifacts available to everyone, and would not change the approach. The Register records one discrepancy: Lorenc dates the rumours to Monday 10-19, PHP to Tuesday afternoon.

Exploitation. Amazon's CISO (AWS Security Blog, 2026-10-21): a honeypot attempt on 10-17 from a commercial anonymisation network while the bugs were under embargo, the earliest of several proofs at about 02:00 UTC on 10-21, varied payloads from other anonymised infrastructure between 02:00 and 08:00 suggesting multiple actors, and proofs used against sensors within hours of the 14:00 release; Amazon calls PHP2Shell "broadly exploited in the wild" and says it is unclear whether any attempt would have succeeded against real systems. Cloudflare turned on WAF rules by default at 03:02 UTC on 10-21 and saw attack traffic and payload changes to evade them; its CEO's X post, quoted by SecurityWeek, reported thousands of attempts in the ten hours before the announcement, hundreds of thousands within two hours after, and millions by the time of the post. SecurityWeek also reports watchTowr's note that none of the circulating proofs achieved RCE, JFrog finding fake proofs and prank malware on GitHub, and VulnCheck seeing one unsuccessful webshell attempt. Exposure counts, all as of 10-21 and each vendor's own: Censys about 1.57 million unpatched hosts with identifiable versions; VulnCheck more than 2.6 million internet-facing PHP hosts, at least 1 million end of life; VirusTotal about 1.1 million IPs announcing a version. Neither CVE was in CISA's KEV catalog as of 10-22 (both were added on 10-26, see the update below); CISA's 10-21 alert says no observed exploitation at publication and tells operators to take unpatched systems offline, including 8.1 and older. BambooHR and several Dutch government services went offline as a precaution (The Hacker News).

Mitigations the vendor lists, and their limits. For CVE-2026-109618: set memory_limit=-1 administratively so applications cannot restore a finite limit, keep post_max_size low and enforce decoded request size at the frontend, and avoid RLIMIT_AS and RLIMIT_DATA, which trigger the vulnerable path. For CVE-2026-109619: session.upload_progress.enabled=0 and, on 8.5, fatal_error_backtraces=0, each followed by a restart of every worker; pm.max_requests=1 if performance allows. The advisory states there is no complete configuration mitigation. After updating, review memory_limit and post_max_size: the fix adds a hard limit that ends the process and skips shutdown handlers.

Why it is here: PHP is not the stack this corpus centres on, but it is the runtime under a large share of the web that generated apps talk to, and under Laravel and WordPress projects that coding agents maintain. The disclosure is also the first mass-exploited runtime bug the corpus has seen whose discovery, exploit development and embargo break all ran on AI tooling, which is the shape Amazon's post says defenders should now expect: hours, not days, from advisory to attempts.

Am I affected?

  • php -v on every host, including PHP embedded in other software and in container images. Patched: 8.2.35, 8.3.36, 8.4.27, 8.5.12. Distribution packages may carry the fix under an older version string; check the changelog for the CVE ids.
  • Any PHP that serves web requests is in scope. mod_php is the confirmed exploit target and the highest risk; FPM is exposed to CVE-2026-109619 through the session lifecycle and conditionally through early INI diagnostics.
  • Indicators the researchers recommend (via The Hacker News): unusual multipart requests followed by memory-limit errors or bursts of HTTP 500s, oddly large PHPSESSID cookies, unexplained worker restarts. Amazon adds: POST form uploads carrying a session upload-progress field, unexpected process execution or file changes on web servers.

If you are affected

  1. Update to a patched release now, internet-facing hosts first. On 8.1 or older with no vendor package, apply the source backports on the php-src repository's PHP-7.4, PHP-8.0 and PHP-8.1 branches named for the two CVE ids, or take the host offline, as CISA advises.
  2. If you cannot update immediately, apply the interim settings above and restart all workers, knowing they are partial. Keep a WAF in front.
  3. Investigate from 2026-10-17, not from the disclosure date, per Amazon. If a worker shows the indicators above, treat the host as compromised: if your webapp was compromised, then rotate everything the worker could read, per rotating cloud credentials. CVE-2026-109618 can also leak other requests' memory, so session tokens and keys that passed through the worker count.

Prevention

  • CI/CD hardening: a runtime pin in a Dockerfile is a vulnerability you have to notice; rebuild on security releases.
  • Credential hygiene: a worker-memory leak is bounded by what the worker holds.

Update 2026-10-26 — CISA added both CVEs to KEV on 2026-10-26 (due 2026-10-29); working shells seen on honeypots; a third bug, CVE-2026-115560, waits for a regular release

KEV. The KEV JSON read at the end of 2026-10-26 (catalog released 2026-10-26T22:24Z) lists CVE-2026-109618 and CVE-2026-109619 with dateAdded 2026-10-26 and dueDate 2026-10-29, three days instead of the usual three weeks. SecurityWeek's morning article the same day still said neither was listed, so the addition happened during 10-26.

Working shells. SecurityWeek (10-26): across three honeypots run by Adel Karimi (Perplexity), 35 web shells landed on 10-24 from two source addresses, against Apache mod_php configured with a single worker; Marcus Hutchins is quoted that the exploit's reliability depends on that configuration and that multi-worker and FPM deployments remain much harder. The Hacker News (10-25) reports Unit 42 retracting an earlier claim of successful exploitation and CYFIRMA attributing, with moderate confidence, scanning from 21 nodes against 216 targets to a DPRK-linked group.

Third bug. The Register (10-23): CVE-2026-115560 is a further stale-state issue the researchers found; it needs the session.serialize_handler to be switched from the default, so PHP will fix it in the next regular release rather than an emergency one; the interim setting is session.upload_progress.enabled=0, already in the mitigation list above, and the circulating proofs target mod_php rather than FPM.

Embargo dispute. Socket (10-21) has the fullest side-by-side of the PHP Foundation's and Chainguard's timelines; the 07:41 UTC image publication and Dan Lorenc's statement are as reported in the body above. The Hacker News (10-26) notes PHP's second Windows build update in a week for the same fixes.

Update 2026-10-27 — one week in: Wiz counts exposed vulnerable hosts down about 67% and under 53% of initially affected organisations still exposed; Censys counts 32.51 million services on affected versions; Karimi's honeypot result is "confirmed RCE with usable memory disclosure"

Remediation trend (Wiz, 10-27, its own telemetry). An approximate 67% decrease in the daily number of distinct Internet-exposed vulnerable machines over the past few days; the share of those on PHP 7.3 or earlier, which got no official backport, down from 8.3% to 5.7% over five days; organisations with at least one exposed vulnerable instance down about 47.9%; at the one-week mark "less than 53% of initially affected organizations remain vulnerable". Wiz says the data shows the trend, not which remediation (patch, upgrade, retire, restrict) did the work, and that scan coverage affects the numbers.

Exploitation (Wiz and The Hacker News, 10-27). Wiz saw no successful end-to-end exploitation in its telemetry and found no public general proof of concept, while partners privately disclosed exploits that work against a variety of targets; every captured first-stage attempt against its honeypots exhausted PHP memory, and the two scanners that failed against Wiz's honeypots succeeded against Adel Karimi's, which Wiz calls a likely factor in the KEV decision. Karimi's account, as The Hacker News reports it from his 10-24 post: confirmed RCE with usable memory disclosure, an 800 KiB decoded cookie dump, and a function address derived from it reused in a later payload, on a deliberately favourable single-worker mod_php setup that measures nothing about other worker counts, builds or applications. Wiz also notes that activity using the PHP2Shell name from one source relied on session poisoning plus a separate local-file-inclusion endpoint and did not exploit either CVE. The Hacker News adds Censys's estimate of more than 32.51 million PHP services still on an affected version and a vendor list (ABB, Broadcom, Citrix, Drupal, F5, IBM, Okta, Siemens, SonicWall, Splunk, WordPress) that has published advisories. Nothing in these changes the action: patch, and if you cannot, the mitigations above.

Sources