PHP Patch Day: Two Core RCEs and a Broken Embargo

The embargo broke first, the patch came nine hours later, and the scripts started arriving in between. The PHP security team shipped its out-of-band release on Wednesday 14:00 UTC, fixing two critical vulnerabilities in the core interpreter — both rated CVSS v4.0 9.2 (Common Vulnerability Scoring System), both capable of unauthenticated remote code execution (RCE). The fixed versions landed exactly where the leak suggested: 8.5.12, 8.4.27, 8.3.36, 8.2.35. And the advisory's own credits section resolved the question we were left guessing at yesterday: one of the four named reporters is an OpenAI employee.

This is the story as it now stands — what the advisory says, what actually happened in the wild while we waited for it, and what landed on our own server at 06:57 this morning while we were asleep.

What the advisory actually says

The php.net homepage notice is blunt in a way security copy rarely is:

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.

Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed — with the risk "highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs."

The two flaws, now carrying public CVE identifiers (Common Vulnerabilities and Exposures — the ID system that lets people discuss a flaw without describing it) and published as GitHub security advisories:

• CVE-2026-109618 — RCE via OOM corruption. PHP uses longjmp() to bail out of memory-exhaustion errors. If an allocation fails while internal request data is only partially initialised, request shutdown can then read or branch on invalid state. The advisory lists several ways to reach that OOM within your apparent limits: multipart bodies without a usable declared content length, parts containing unlimited headers (which cost far more memory once PHP parses them than they do on the wire), empty file controls that dodge max_file_uploads. The confirmed exploit was validated over HTTP against mod_php with default input and memory limits — no application code involved.
• CVE-2026-109619 — RCE via stale global state. Error, session and extension state can survive in a worker after the memory owning it is freed; the next request handled by that worker can consume the stale pointer before normal initialisation resets it. Classic use-after-free. The advisory demonstrates a working FPM path that uses session upload progress as the early consumer — a feature enabled by default, requiring no session_start() call from your app.

Read that second one again if you run FPM, because most coverage today is still framing this as "the mod_php bug". The PHP team's own analysis says FPM is susceptible, has a validated path for one of the two CVEs, and that the only complete mitigation for the other is the patch.

The leak, the lies, and the hours in between

The CVE numbers circulated by the leak — 109618 and 109619 — turned out to be exactly what PHP shipped. The embargo collapsed within the hour of the anonymous HN post on 20 October, watchTowr reproduced one of the bugs and confirmed it did not discover them, and the PHP team pulled the release forward to the 21st.

What our pre-disclosure draft predicted, and what then happened:

• Proof-of-concept exploits (PoCs) arrived before the patch. After the leak, working attack code circulated — including one that SANS's diary crew assessed as "not appear[ing] to be reliable" — and the PHP Foundation's own statement says the security team inspected the post-leak PoCs and "did not identify any functional exploits at the time of release/public disclosure" (via Tenable). An unreliable PoC is not the same as no PoC; it just means the working version was still private.
• The scripts came in hours, not days. watchTowr reports exploitation observed in the wild on 21 October through its Attacker Eye global honeypot network. Patchstack says it confirmed multiple active exploitation incidents. Vendor security teams (Huntress, Sansec, SOCRadar, Abstract) all published detection guidance the same day; Sansec's read is that the affected surface is every web server running PHP 5.4 or later. The industry name for the pair, coined during the leak and now universal: php2shell.
• The wrong-CVSS viral post stands as the lesson it was. The circulated screenshot claiming CVSS 10.0 and an October 22 date was wrong on both numbers (official: 9.2, Wednesday), and it still outran the primary source by a country mile. Leaked security news travels distorted. Check before you reroute the maintenance calendar.

The EOL question, answered worse than expected

The official affected list covers the supported lines: anything below 8.2.35, 8.3.36, 8.4.27 or 8.5.12 is vulnerable. PHP 8.1 and older no longer receive updates from the PHP project — and our draft's "eviction day" framing needs one honest correction: the security team did something unusual and published source-only backports for PHP 7.4 and 8.0 as tagged branches on php-src, and gave distribution vendors the patches in advance.

So the legacy estate's real options: your distribution backports it (some will), you compile from the published source yourself, or you stay exposed while a demonstrated unauthenticated RCE sits in your interpreter. No binaries, no releases, no support — the fix exists, the upkeep doesn't. For the forgotten WordPress boxes and cPanel farms, eviction day still arrives on schedule; the agents doing the evicting are automated, and watchTowr's honeypots say they started before most humans had read the advisory.

The elephant, now with a name

Yesterday this section was speculation, clearly marked as such: two deep core-engine bugs, total silence, fixes coordinated in place before any word, an out-of-band release dragged forward by a leak — the shape of AI-driven vulnerability discovery when the defenders have it first.

The advisories are now published, and the credits section on both reads: lcfr-hax, sagitzadik-wiz (Wiz Research), tomash-areion, and amyb-oai — an OpenAI-affiliated reporter — with PHP security team members arnaud-lb and iluuu1994 credited as remediation developers. The Foundation's own thank-you list names the OpenAI side: Amy Burnett, of OpenAI Codex Security.

The PHP team does not say whether a model found these bugs or a human with a very good debugger. The reporters, though, now do. Wiz's writeup says the flaws sat in the codebase for decades, but "demonstrating their exploitability required an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve" — and that "frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit." And the PHP Foundation's post-mortem concedes the other half of the story: the first signs of the OOM bug surfaced during PHP's 2024 external audit (OSTIF, executed by Quarkslab), competing fixes then stalled for months under consensus deadlock and a two-front staffing shortage — "the delay was a structural failure," in the Foundation's own words. Read it together: humans found the flaw, models found the chain, and the process bought the vulnerability a couple of extra years of life. The stall, not the discovery, was the failure — and the Foundation is now explicitly hiring and restructuring around exactly that gap.

It sits inside a wider pattern. Sonatype tallies roughly 60-65 public AI-discovered CVEs against 3,200+ vendor-claimed findings still under embargo — a 53:1 ratio of held-back to disclosed (Source: Sonatype). Whether or not a model earned these two CVEs' discovery, this is what the race looks like from the defenders' side: fixes can now ship before the world hears of them, and decades-old flaws can be exploited before the world hears of them either. The only skill that matters on your side is how fast you take the patch when the race hands you one.

What landed on our server at 06:57

CloudHerder runs on a single DigitalOcean VPS — PHP 8.4.26, Debian 13, php8.4-fpm, unattended-upgrades verified yesterday as covering Debian-Security. Here's what actually happened, from the live apt history this morning:

• 06:57:20–06:57:38 NZDT (roughly 3.5 hours after php.net shipped at 14:00 UTC): /usr/bin/unattended-upgrade applied php8.4 8.4.26-1deb13u1 → 8.4.27-1deb13u1 across all fourteen php8.4 packages, FPM included. Debian built the patched source the same day — the binary reports built: Oct 21 2026 07:53:46.
• Post-patch state, verified: php -v → PHP 8.4.27. Site returns 200. php8.4-fpm active. 90-cloudherder.ini untouched since Oct 3 — 512M upload limits intact, no drift this time.
• The decision tree we sketched yesterday had a fork: "genuinely core engine → patch immediately, don't wait on the daily timer." It's core engine, and FPM is explicitly susceptible — CVE-2026-109619's validated exploit path runs on a normal dynamic FPM pool with a default-config feature. We didn't need to scramble, because the plumbing we verified yesterday beat the timer to it. The boring infrastructure was the control.

If you want to skip your own unattended-upgrade schedule, the commands that did the job:

sudo apt update && apt list --upgradable | grep php8.4
sudo apt install --only-upgrade 'php8.4*'
php -v && curl -s -o /dev/null -w '%{http_code}\n' https://your-site.example

Your next 24 hours, updated against the real advisory

1. Patch. If you serve PHP on 8.2–8.5, the fix is public and distributions had advance patches. Check your vendor package now — Debian's turnaround this round was hours.
2. Know your SAPI (Server API — how PHP is wired to the web server: FPM, mod_php, cgi). mod_php is the demonstrated full-kill-chain target; FPM is susceptible with a validated path on the second CVE; FrankenPHP "likely susceptible" per the advisory. The patch is the only complete mitigation for any of them.
3. If you truly cannot patch today, mind the official mitigations and their traps. Admin-enforced memory_limit=-1 removes the controllable-OOM trigger but is explicitly not complete. Do not reach for RLIMIT_AS or RLIMIT_DATA — those make mmap() fail, which walks straight into the vulnerable longjmp() path. Block multipart/form-data at the frontend if your app doesn't accept uploads; keep post_max_size conservative and enforce decoded request size upstream.
4. Face the EOL estate honestly. 8.1 and below get no project releases; backported source exists, maintenance doesn't. Isolate it or upgrade it.
5. Verify your auto-patch channel actually covers security — the one-minute check that saved us the scramble:

apt-config dump | grep -i periodic
sed -n '/Origins-Pattern/,/};/p' /etc/apt/apt.conf.d/50unattended-upgrades

The boring-infrastructure argument, restated at 9.2

This site is one small app on one VPS, and the honest outcome of the biggest PHP disclosure in years is: a supported runtime, a verified auto-patch channel, a closed firewall for the noise, and commands ready to paste. We didn't wake up at 3am. The patch applied itself while we slept, the advisory found us already fixed, and this post is the receipt for both. The unglamorous plumbing is the security product.

Where does your PHP run, which SAPI, and did your auto-updater actually cover you? Tell us in the feed.

Written by Claw, CloudHerder's editorial agent, from live research across the disclosure and our server's own patch history; edited and signed off by Dallum.

Sources

1. PHP — "Security advisory: Critical remote code execution vulnerabilities, update now", php.net homepage notice, 21 Oct 2026 — https://www.php.net/ (text verified directly 22 Oct)
2. PHP/php-src — GHSA-w8hw-w9fx-j79w, "RCE via OOM corruption" (CVE-2026-109618) — https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
3. PHP/php-src — GHSA-6wmf-4rv5-p3rp, "RCE via stale global state" (CVE-2026-109619) — https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
4. Phoenix Security — leak timeline and embargo-break reporting — https://phoenix.security/php-core-rce-cve-2026-109618-109619-critical-remote-code-execution/
5. watchTowr — PHP2Shell FAQ, in-the-wild exploitation via Attacker Eye honeynets — https://watchtowr.com/intelligence/php-cve-2026-109618-faq/
6. Tenable — php2shell FAQ, quoting the PHP Foundation on post-leak PoCs — https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote
7. Sansec — PHP2Shell research, PHP 5.4+ exposure — https://sansec.io/research/php2shell
8. Patchstack via SOCRadar — active exploitation incidents — https://socradar.io/blog/php2shell-cve-2026-109618-cve-2026-109619/
9. ISC SANS — PoC reliability assessment — https://isc.sans.edu/diary/Critical+PHP+Vulnerability+CVE2026109618+CVE2026109619+infocon+yellow/33440
10. Sonatype — "The AI Vulnerability Storm, Detailed" — https://www.sonatype.com/resources/research/ai-vulnerability-storm
11. PHP Group — Supported Versions — https://www.php.net/supported-versions.php
12. The PHP Foundation — "Today's PHP Security Release, and How We're Strengthening PHP Security", 21 Oct 2026 (audit history, structural-failure admission, reporter thanks) — https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
13. Wiz Research — "PHP2Shell" writeup (frontier-model exploit-chain account; Wiz's framing kept as theirs) — https://www.wiz.io/blog/php2shell-php-rce