Two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, were patched on October 21. Thirteen and a half hours earlier, an independent researcher had already published a reconstruction of them, apparently built from a handful of public clues.
On October 21, 2026, at 14:00 UTC, PHP shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix PHP2Shell: two unauthenticated remote code execution flaws rated 9.2 under CVSS 4.0.
The release was meant to land a day later. A leak moved it up. And by 00:30 UTC that night, a researcher posting as J4ck3LSyN had already put a reconstruction of the bugs on X, PoC included.
That part of the story says more about where vulnerability disclosure is heading than the bugs themselves.
What PHP2Shell actually is
Both CVEs come from how PHP handles fatal errors, out-of-memory errors in particular. When a request crosses memory_limit, PHP bails out with longjmp() and skips its cleanup. The next request on the same worker inherits memory that is half-initialized or already freed.
- CVE-2026-109618, "RCE via OOM corruption": request shutdown trusts data that was only partly initialized.
- CVE-2026-109619, "RCE via stale global state": a later request reuses state whose memory was already freed, for example through session upload progress.
No vulnerable application code is required. Wiz Research chained four underlying bugs into unauthenticated RCE on the latest WordPress, Drupal and Joomla images. The vulnerable code dates back to PHP 5.4 (2012), and Unit 42 counts more than 22.6 million exposed instances that are potentially vulnerable.
The bugs were found with frontier AI models. Wiz found its first one on August 19 and had RCE against Drupal the next day. Wiz calls it "an AI inflection point."
From leak to patch in 23 hours
Calif, working with OpenAI, and Wiz Research reported the bugs to PHP in August. The embargo was set to lift on Thursday, October 22, at 11:00 ET.
It didn't hold. On October 20 at 15:20 UTC, an anonymous "Tell HN" post announced both CVEs, and watchTowr confirmed within hours that they were real.
From leak to patch: 7 milestones, UTC
The patch shipped 22 hours and 40 minutes after the leak, and 25 hours ahead of the original embargo. The public PoC beat it by thirteen and a half.
The rediscovery: right target, wrong first chain
At 00:30 UTC on October 21, J4ck3LSyN posted: "I have successfully recreated & lab/field tested CVE-2026-109618 / CVE-2026-109619." The post, seen 2.6 million times, pointed at PHP's session.upload_progress handler. A linked page added a write-up and a PoC archive, credited to two co-authors. It doesn't say how they found the lead.
The public record was thin: PHP's notice (two critical flaws, CVSS 9.2), the pulled Hacker News post (PHP 5 onwards, both CVE IDs) and watchTowr's lab reproduction. Our reading, not theirs: "critical, unauthenticated, since PHP 5" points to code that runs before the application. Multipart parsing and session upload progress, on by default, are among the few candidates.
Nine hours after the leak, the team was looking in the right place.
The first chain didn't hold. The same day, the page added a correction: that path was "DEAD at the addref." What survived, a cross-request use-after-free triggered by a memory_limit bailout, sits very close to the confirmed session path of CVE-2026-109619.
But it wasn't code execution: the team downgraded its own finding to CVSS 5.3. Its justification fits in one line:
"A pre-patch mitigation shouldn't be a subscription perk."
The point stings. Palo Alto lists a signature available since October 20, and Cloudflare pushed WAF rules hours before the patch. Still, don't run that kind of archive on a workstation: fake exploits for hot bugs are a classic trap for security researchers.
Embargoes now buy hours, not days
The real disclosure date is no longer the advisory. It's the first public signal.
- A rumor is enough to compress the schedule. As ABGEO put it, an unsourced post cost every PHP team a full day: the release moved up by 25 hours.
- A pre-announcement guides attackers too. A severity score and a version range point at a small slice of code. Pre-announcing is still the right call, but it starts a race.
- Embargoes are asymmetric. Distributions and security vendors had patches or rules in advance. PHP 8.1 and older get no official fix, and about 884,000 exposed hosts still advertised those versions on October 20, per Mallory data cited by Check Point.
- Attacks don't wait. Cloudflare reported early attacks at 07:43 UTC, hours before the advisory. A European government took its website offline as a precaution.
We recently wrote that the gap between disclosure and first exploitation had shrunk to about ten hours. With PHP2Shell, attacks came before the advisory. With models that can find and weaponize a bug within days, that window will keep closing.
What to do now
Updating is the only complete fix, and the write-ups are now public.
- Inventory every PHP runtime, including containers, appliances, hosting panels and CMS stacks.
- Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, restart every worker, and check the running version. Start with internet-facing Apache and mod_php, where PHP rates the risk highest.
- Handle 8.1 and older with a vendor backport, an upgrade or isolation. PHP published minimal source backports for 7.4, 8.0 and 8.1.
If patching has to wait, PHP's advisory lists partial mitigations. None of them makes an installation safe.
To spot attempts, watch for multipart requests followed by memory-limit errors or bursts of HTTP 500s, oversized PHPSESSID cookies, and shells or download tools spawned by PHP workers (Huntress).
What this means for vulnerability operations
PHP2Shell is exactly the scenario Vulnerability Operations exist for. The useful work happened between the notice and the patch: which assets run PHP, which branches are end-of-life, which servers face the internet. None of that can be built in 18 hours.
Scores don't help in that window either. Until the advisories went out at 13:34 UTC, there was no CVSS vector, no EPSS score and no KEV entry.
That's why we build Hackuity around exposure context first. PHP2Shell is already referenced in SmartEx², our Smart Exposure Explorer, enriched with Hackuity's vulnerability and exploit intelligence. It will also join the catalog of CVEs that Probe, our AI agent for exploit validation, can replay. Probe is available today in feature preview, with general availability planned for January 2027.
The question then changes. Not "is this CVE critical?", but "can it actually be exploited on this server?"
The patch date is no longer when the race starts. It's when you find out whether you were ready.
Want to see how Hackuity helps teams act on the first signal? Book a demo.
Sources:
- PHP, pre-announcement (Oct 20) and security advisory (Oct 21)
- PHP, GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- Wiz Research, PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet
- Unit 42, Threat Brief: CVE-2026-109618, CVE-2026-109619
- Sansec, Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619
- J4ck3LSyN, post on X and php-up-2026 page (unverified PoC archive)
- BleepingComputer, PHP warns admins of two critical flaws
- Huntress, Rapid Response: php2shell
- Check Point, php2shell: What We Know
- ABGEO, php2shell, Two Critical PHP Bugs Leaked Before the Patch
- Wikipedia, PHP2Shell
VR-1 | Property |
|---|---|
Model type | Post-trained cyber reasoning model |
Primary specialization | Multi-domain enterprise attack-chain discovery |
Starting condition | A scoped foothold and a concrete objective |
Operating surfaces | Cloud, identity, runtime, code, CI/CD, SaaS, and organizational context |
Success signal | Execution-verified completion of the objective |
Primary evaluation | IntrusionBench |
Preliminary result (preview) | More than 2× black-box pass@3 over the strongest evaluated frontier baseline |
Trajectory budget | Two-hour wall-clock limit per trajectory, or 250 agent turns (whichever comes first) |
