PHP2Shell: two critical PHP core RCEs leak a day before the patch, and nearly every PHP back to 5.4 is in the bowl
CVE-2026-109618 and CVE-2026-109619 (both CVSS 9.2) give remote code execution in PHP itself. A proof-of-concept video leaked the evening before release, so the patch and the exploit arrived together.
Make PHP run out of memory at exactly the wrong moment, or poke a worker that still holds a previous request's freed state (session.upload_progress is the confirmed way in), and the next thing PHP executes is your bytes.
Two bugs in PHP’s own engine, not in some framework or plugin. Nearly every PHP release back to 5.4 is
affected by at least one of them. Apache mod_php is the highest-risk setup, but PHP-FPM, php-cgi,
FrankenPHP and LiteSpeed are all in scope.
The disclosure was planned for October 22. On the evening of October 20 a proof-of-concept video from Calif, one of the reporting teams, went public by accident, and PHP pushed its releases out on October 21 at 14:00 UTC. So for once, defenders and attackers started the race at the same time.
Is it exploited? It depends on whom you ask. Patchstack’s partners and watchTowr saw real attack attempts within hours. Cloudflare saw early attempts too. Sophos had no reports of exploitation, and nobody had confirmed a successful break-in at the time of writing. We grade by the worst credible case: public PoC + default configuration + basically the whole web = L5.
Turning off session.upload_progress is not a fix. It only cuts the confirmed path to
CVE-2026-109619. The out-of-memory bug, CVE-2026-109618, does not need it.
CVE-2026-109618CVSS 9.2If PHP runs out of memory at the wrong moment, it can bail out while internal request data is only partly initialised. This path does not need session.upload_progress.
In plain poop: the toilet gets installed with only half its bolts, and someone sits down anyway.
CVE-2026-109619CVSS 9.2Request-owned global state survives after its memory is released, and a later request on the same worker uses it. session.upload_progress is the confirmed trigger.
In plain poop: you flushed it, but it came back up in the next person's stall, and now it runs your server.
Run php -v on each box, then type the version or pick the closest match.
| Branch | Safe from | Status |
|---|---|---|
| PHP 8.5 | 8.5.12 | Supported, patched |
| PHP 8.4 | 8.4.27 | Supported, patched |
| PHP 8.3 | 8.3.36 | Security fixes only, patched |
| PHP 8.2 | 8.2.35 | Security fixes only, patched. EOL Dec 31, 2026 |
| PHP 8.1 and older | none | End of life. Distro / LTS vendors and source backports for 7.4–8.1 only |
; PHP2Shell interim hardening (partial!) ; blocks the confirmed CVE-2026-109619 session path only session.upload_progress.enabled = Off
Then reload PHP-FPM / Apache. php.net is clear that upgrading is the only complete fix: this does nothing for CVE-2026-109618. Capping request body size at your proxy also raises the bar.
Oct 20, 2026
The details escape the bathroom
A Hacker News post says disclosure is due Oct 22. Around 20:00 UTC Calif accidentally publishes a proof-of-concept video. PHP posts an advance notice the same day.
Oct 21, 03:02 UTC
Cloudflare switches on default WAF rules
Oct 21, 07:34 UTC
Patchstack hosting partners report exploitation incidents
Its 13:57 UTC telemetry update shows probing, with no hard evidence of breaches.
Oct 21, 14:00 UTC
PHP ships 8.5.12, 8.4.27, 8.3.36 and 8.2.35
Linux distributions and LTS vendors got the patches in advance.
Oct 21, 14:19 UTC
watchTowr sees active exploitation attempts
watchTowr also reproduces CVE-2026-109618. Sophos says no in-the-wild exploitation has been reported.
We list each claim and who made it. Primary sources (the vendor, the researcher, the registry) are marked. Where reports disagree, we grade by the worst credible case.