PHP2Shell: two critical flaws at the heart of PHP

On 21 October 2026, the PHP team rushed out fixes for two critical flaws dubbed PHP2Shell: CVE-2026-109618 and CVE-2026-109619. Rated 9.2 out of 10 (CVSS 4.0), they allow remote code execution without authentication. They do not affect one CMS or framework, but the PHP engine itself: potentially, every site written in PHP.

Two memory bugs in the request lifecycle

To serve a page, PHP sets up per-request state, then cleans it up at the end. Both flaws live in that cycle:

• CVE-2026-109618 — when an out-of-memory error interrupts a request, PHP can abandon half-initialised data; the cleanup phase then treats it as valid;

• CVE-2026-109619 — PHP can keep request-specific state after the matching memory has been freed. If the same process handles the next request, that stale state can be read before it is reset. The official advisory also mentions possible memory disclosure.

Both are use-after-free bugs: an attacker able to trigger these conditions can corrupt the process memory and get it to run their own code.

Who is affected?

Every execution mode that serves web pages is in scope: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team considers mod_php the most exposed. No configuration option fully removes the risk: only updating fixes it.

BranchFixed versionPHP 8.58.5.12PHP 8.48.4.27PHP 8.38.3.36PHP 8.28.2.35PHP 8.1 and olderno official release

For 8.1, 8.0 and 7.4 there are only unreleased source patches, and patched builds from some distributions or hosts.

A rushed disclosure

• 11 August: the root cause is reported to the PHP security team, further attack vectors follow on 24 August;

• 22 October: planned coordinated disclosure date, under embargo;

• 20 October: an anonymous post announces the flaws publicly; PHP brings the release forward;

• 21 October, 14:00 UTC: fixed versions released.

The PHP Foundation acknowledged that the underlying issue had been flagged in an audit as early as 2024, and called it a structural failure of its security process.

The numbers

PHP is (almost) the whole web

• ~70% of websites whose server-side language is known run PHP (W3Techs, August 2026);

• of those, 62.5% are on PHP 8, 29.4% still on PHP 7 and 8% on PHP 5;

• within PHP 8, 8.0 and 8.1 still account for nearly a quarter of installs (17.8% + 7%).

Put together, more than half of PHP sites run a branch that will get no official fix.

Millions of exposed servers

• Censys counted 2.58 million internet-facing PHP hosts on 21 October, ~1.57 million of them advertising an unpatched version; the next day it was tracking nearly 3 million;

• Black Kite, using Shodan, lists ~1.9 million exposed PHP hosts; among those showing their version, 72.5% are on end-of-life branches.

Attacks by the million, no confirmed success

• According to Cloudflare, attempts went from a few thousand in the 10 hours before the announcement to tens of thousands in the following 45 minutes, hundreds of thousands within 2 hours, then millions on 22 October;

• some of these attempts aim to enlist servers into a variant of the Mirai botnet;

• as of 22 October, no successful exploitation was confirmed: CISA had observed none and had not added the flaws to its Known Exploited Vulnerabilities catalogue. Public proofs of concept only work on very specific combinations of OS, version and web server.

Millions of attempts, no confirmed success… so far. Exploits improve fast: the only reliable answer is still to move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35.

Sources

• Rapid7 — technical analysis

• Tenable — FAQ

• Black Kite — exposed servers

• Security Affairs — attack attempts

• The Hacker News — Mirai botnet

• W3Techs — PHP market share