PHP2Shell Is Patched (8.5.12, 8.4.27, 8.3.36, 8.2.35). Now Patch — the Exploits Are Already Circulating.

Yesterday, PHP's two critical RCE flaws were still a schedule: a patch at 14:00 UTC and a playbook for the hours before it landed. The patch has landed — PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 — and the October 2026 PHP security release is no longer about preparing. The exploits are circulating while most of the web is still on the old binaries.

The four versions that end this: 8.5.12, 8.4.27, 8.3.36, 8.2.35

Each php.net announcement for the October 21 release calls it what it is: "a security release fixing two critical vulnerabilities (CVE-2026-109618, CVE-2026-109619)." Advisories went public at 13:34 UTC, CVE records hit cve.org by 13:54, the fixed versions shipped at 14:00 UTC, and NVD had both analyzed (CVSS v3.1 9.8) by 17:00.

That 9.8 deserves one honest sentence: PHP's own 9.2 (CVSS v4.0) is the number to use; NVD's 9.8 is the same flaws under an older scoring version. Neither is the leak's made-up 10.0. The severity is real; the inflation wasn't.

The version table, from the advisories:

• PHP 8.5 — vulnerable 8.5.11 and earlier → fixed in 8.5.12 (security support ends Dec 31, 2027)
• PHP 8.4 — vulnerable 8.4.26 and earlier → fixed in 8.4.27 (ends Dec 31, 2026)
• PHP 8.3 — vulnerable 8.3.35 and earlier → fixed in 8.3.36 (ends Dec 31, 2027)
• PHP 8.2 — vulnerable 8.2.34 and earlier → fixed in 8.2.35 (ends Dec 31, 2026)

PHP 8.1, 8.0, and 7.4 get no official release — only source backports, no binaries. Per mySites.guru, 22.7% of the sites they monitor run PHP 8.1 or older. Yesterday's blunt version holds: if you can't upgrade today, isolate.

What the flaws actually do, now that the advisories are public

The embargo's lift brought real mechanics, and they're weirder than the leaked upload speculation suggested. Both flaws are memory bugs in PHP's engine — not in WordPress, not in your framework. The vulnerable code is in PHP itself: even a "Hello World" page on a vulnerable build is exposed.

CVE-2026-109618 — RCE via out-of-memory corruption. When PHP runs out of memory mid-request, it can get interrupted while its internal request data is only half-initialized; the cleanup path then treats that broken data as valid. Complete RCE was validated over HTTP against mod_php — one unauthenticated request, before any application code runs — and demonstrated against stock WordPress, Drupal, and Joomla container images. Reachable paths include multipart-upload tricks: parts with no declared content length, header-stuffed fields, piles of empty file fields. PHP-FPM is susceptible in theory; no complete FPM exploit has been shown.

CVE-2026-109619 — RCE via stale global state. Internal state tied to a request can survive after its memory is freed, and a later request handled by the same worker can use it before it's reset. Session-lifecycle RCE was validated against mod_php and PHP-FPM (the FPM path needs a suitable application operation). Confirmed trigger paths include session upload progress — on by default — and PHP 8.5's fatal_error_backtraces.

One detail in the 109619 advisory deserves its own line: the researchers confirmed it can disclose worker memory — passwords, tokens, API keys, certificates — without ever achieving code execution. Your secret scanner will not find this in your code. The leak is below your code.

The advisories' bottom line: "there are no complete mitigations — updating is the only safe choice." Config tweaks reduce exposure; they are not a fix.

The last 24 hours: leaked PoC, live attack traffic, sites going dark

PoCs are circulating CERT-EU's advisory 2026-018 says "initial proofs of concept have begun to circulate," which "raises the likelihood that attackers are already exploiting the vulnerabilities." One already escaped early: Calif — one of the credited research outfits — accidentally posted a working PoC video around 20:00 UTC on October 20, hours before the release. PHP's "no functional exploits at release" statement expired the moment the PoCs went public.

Attack traffic started before the patch existed. Cloudflare turned its WAF rules on at 03:02 UTC on October 21 — eleven hours before release — and says it has "observed attack traffic targeting our customers," with attackers already mutating payloads. Its advice is the right one: WAF rules are a seatbelt, not a fix. watchTowr's honeypots caught "active exploitation attempts" at 14:19 UTC, nineteen minutes after release; none had succeeded at last report. Patchstack, through its hosting partners, reports multiple active exploitation incidents.

People are pulling sites offline. When BreachForums and Dread go dark as a precaution, it's a signal. More consequentially: Dutch government portals (MijnOverheid, DigiD, parliament, the national cyber center), French Interior Ministry sites, Finnish services, a Danish school platform, and privacy org noyb all went offline. The US NSA told agencies to take systems offline if they can't patch; the UK's NCSC said the same.

The patching playbook: who gets the fix, in what order, and the traps

• Ubuntu 24.04: USN-8948-1 backports the fix into 8.3.6-0ubuntu0.24.04.13 — the version string looks old because it's a backport. Check the changelog, not the version number. Debian 12/13 shipped fixed builds via DLA-4848-1 and DSA-6574-1.
• Ondřej Surý's PPA: all four fixed versions by 13:36 UTC, plus a backport for 8.1.
• Remi's RHEL repo: missed release day entirely — RHEL-family admins were told to switch to distribution packages or build from source.
• Docker / Alpine: trailed by hours. An official php image rebuild at 15:59 UTC still shipped 8.5.11. Verify the digest you pulled actually contains the fix — don't trust the tag.

Now the order of operations is executable:

1. Find every PHP. php -v on every web root — app servers, panels, containers, CI runners, appliances. One line per binary, with its SAPI. Most teams find a PHP they forgot.
2. Patch internet-facing systems first, in order of exposure — and mod_php hosts before FPM ones, since that's where the demonstrated exploit path lives.
3. Restart every PHP worker after updating. The patch doesn't apply to running processes; old workers still serving are still vulnerable.
4. On EOL PHP (8.1 and older): no official fix exists. Isolate internet-facing apps from public networks, WAF them, and treat this as the forcing function for the upgrade you kept postponing.
5. WordPress on shared hosting: updating core, themes, and plugins does not fix this — the flaw is in the runtime underneath WordPress, and your firewall plugin fires after the attack does. Ask your host, verbatim: "Has the PHP fix for CVE-2026-109618 and CVE-2026-109619 been installed on my server?" Then check Tools → Site Health → Info → Server yourself.
6. After patching, hunt. Look for web workers spawning shells or interpreters. Exploit attempts now arrive within hours of disclosure — this time they started before it.

One fair objection: is this fear-mongering? The score was 9.2, not 10, and no successful attacks have been confirmed. The numbers cut the other way. Attackers got a full day of awareness before the patch existed; PoCs circulated within hours of release; Cloudflare was absorbing attack traffic eleven hours before disclosure. And the reach is total: ~70% of websites run PHP, the vulnerable code is in the engine, and the attack fires before a single line of your application runs. Patching today costs almost nothing. A web shell next week costs everything.

If you read yesterday's pre-release playbook, here's the one-line update: the fixed versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35, the exploits are real, and the package upgrade is the whole defense. Everything else is commentary.

References

• php2shell.com — the researchers' disclosure site
• Rescana: PHP RCE flaws — patch timeline
• SOCRadar: PHP2Shell CVE-2026-109618 & CVE-2026-109619
• The Register: PHP devs publish critical bug fix
• The Hacker News: PHP issues emergency patches
• Patchstack: PHP major vulnerability alert
• Veduis: sysadmin triage and hardening guide
• MagicWP: patch guide
• Tenable: PHP2Shell FAQ
• mySites.guru: PHP critical security release (WordPress/Joomla)

Follow-up to Two 9.2-Rated Flaws in PHP. The Patch Lands Today at 14:00 UTC — Attackers Got a Day's Head Start.