PHP2Shell fixes shipped, but patched hosts and old PHP versions can still leave sites exposed

Two bugs under one name

On October 21, PHP shipped emergency fixes for two flaws now known as PHP2Shell: CVE-2026-109618 and CVE-2026-109619, each rated 9.2 under CVSS v4.0. According to a dev.to write-up by hisashispace, an attacker with no account can use them to run code on the server, and PHP considers every installation that serves web requests affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is rated highest for mod_php, where PHP says it has a demonstrated exploit that succeeds before any application code executes.

The mechanics differ slightly. In CVE-2026-109618, PHP runs out of memory partway through preparing a request, and the cleanup path then trusts data that was only half-built. In CVE-2026-109619, internal state outlives the memory it references, so the next request handled by the same PHP worker can reuse that leftover state. A dev.to postmortem by The Dev Stack describes both as use-after-free conditions in allocator-adjacent code: pre-auth remote code execution with no login to brute-force, no session to steal and no CSRF token to extract. watchTowr, cited in the hisashispace post, adds that Session Upload Progress, which is enabled by default, is one confirmed route to CVE-2026-109619, meaning most default setups already meet the precondition.

A patch with holes in it

The fixes cover PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older receive no official release: 7.4, 8.0 and 8.1 depend on distribution or LTS backports, while 7.3 and older have no fix at all. The Dev Stack's framing is blunt — on end-of-life branches this is not a vulnerability to mitigate but an upgrade to plan. Hostinger, quoted by hisashispace, says the affected code reaches back at least to PHP 5.4.

Even current sites face a subtler trap. On managed hosting, a patched PHP build can keep its old version number, because Hostinger compiled the fix into versions already deployed; its advised check is the build date, with October 21, 2026 or later meaning patched. ActiveSet's host tracker, referenced in the same post, notes that CloudLinux fixes can leave a patched 8.3 still reporting 8.3.35, and watchTowr warns that the command-line php binary can differ from the interpreter PHP-FPM or Apache actually runs. The practical test is a direct question to the host: was the PHP serving my site built on or after October 21?

Rollouts at major hosts largely finished on October 22, per ActiveSet: WP Engine completed at 01:19 UTC and Hostinger covered all plans except VPS, where customers update PHP themselves, while GoDaddy was only partly patched.

Massive scanning, few confirmed break-ins

Amazon's MadPot honeypots recorded the first exploitation attempt on October 17, four days before the fix, and both posts report that CVE details leaked on Hacker News on October 20, roughly 22 hours before the planned embargo lift. Cloudflare CEO Matthew Prince quantified the surge: thousands of attempts in the ten hours before the announcement, tens of thousands within 45 minutes after it, then millions.

Confirmed compromises remain rare. Palo Alto Networks says attackers chained PHP2Shell with a Linux kernel bug to gain root on PAN-OS firewalls; the research firm Dream found at least 25 compromised devices, and Palo Alto estimates about 0.02 percent of its installed base was impacted. Defiant knew of no WordPress site hacked this way as of October 28, despite logging over 77,000 related requests from more than 2,000 IP addresses, and it observed that working exploits often need tuning per server. Cato Networks found about 96 percent of blocked attacks targeted CVE-2026-109618, with 41 percent attempting code execution. Researcher Marcus Hutchins likened the situation to being roughly halfway to a Log4J-scale event.

Exposure measurements differ by method: Censys saw roughly 1.57 million of 1.58 million version-disclosing hosts unpatched, VulnCheck counted over 2.6 million hosts, nearly all vulnerable, including at least one million on end-of-life versions, VirusTotal identified about 5.1 million PHP IP addresses, and Palo Alto put the possibly vulnerable instance count above 22.6 million.

Reading the early traffic

The Dev Stack's analysis of the MadPot capture argues the first request was a fingerprint of pre-knowledge: one IP, one attempt, and the correct allocator path on the first try, with none of the near-miss noise fuzzing produces. Its advice for responders is to hunt logs from October 17 onward, since the pre-release window holds the skilled-adversary signal while post-release traffic is scanner noise. The post also highlights the maintainers' own postmortem language of "structural failure," pointing to an allocator pattern that has recurred since the mid-2000s. Separately, PHP disclosed a narrower third issue, CVE-2026-115560, on October 23 and shipped rebuilt Windows packages on October 26 for a separate Brotli bug.

Why it matters

PHP2Shell sits in the interpreter rather than in any CMS, plugin or framework, so patching an application was never enough. The two hard lessons for operators are that end-of-life PHP branches have no fix coming, and that a version number on a hosting dashboard is not proof of patch status. With Defiant warning that attackers are still refining their tools, and with the maintainers themselves calling the underlying pattern structural, verifying build dates and reviewing pre-release logs matter more than assuming October's emergency release closed the question.