PHP2Shell’s Patch Is Out. 1.37 Million Servers Will Never Get It
By the end of patch day, 245 servers out of two million had the fix. The other 1.37 million run PHP versions no official patch will ever reach — and the vendors dividing up what's left range from free backports to paid lifelines to a Docker image that ships no fix at all.

By the end of patch day, the count stood at 245.
Of roughly two million.
That’s how many internet-facing servers showed the patched PHP version in OX Security’s Shodan sweep on October 21. The sweep covered roughly two million servers carrying the two critical PHP2Shell flaws, CVE-2026-109618 and CVE-2026-109619. The firm’s finding, published the same day: 99.99% of the PHP servers it could identify were unpatched. The number that matters most isn’t the unpatched count. It’s the unpatchable one: 1.37 million of those servers, 69%, run PHP versions so old that no official fix will ever reach them.
The Wednesday fix landed only where the maintainers still work. 8.1 and below are end-of-life. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 went out at 14:00 UTC, and nothing below that line gets a fix from the project. “All others are end-of-life but are still vulnerable – the vulns date back to versions from 2004 onwards,” security researcher Kevin Beaumont wrote on Mastodon in the post that first flagged the leak.

Mallory counted it a different way and landed in the same place. The security company tallied about 884,000 Shodan hosts admitting to PHP 8.1 or older on October 20 — 59% of the roughly 1.5 million hosts that reported any version — with another 740,000 running PHP but naming no version. Researcher Silas Cutler’s Censys telemetry came in at 1,384,728 vulnerable hosts. And by W3Techs’ site numbers, quoted by Hadrian: PHP runs on 69.3% of websites whose server-side language is known, and 48.5% of those sit on versions with no official fix coming — 0.1% on PHP 4, 7.7% on PHP 5, 27% on PHP 7, 3.8% on the retired 8.0 and 9.9% on 8.1. That’s roughly a third of all websites with a detectable server-side language. The servers that can’t be fixed are the majority.
So the exposed web now has three fates: patched for the current branches, backported for the lucky old ones, orphaned for the rest.
Ondřej Surý’s Debian and Ubuntu packages carry the fix for every end-of-life branch from 5.6 to 8.1 — for free. Ubuntu’s own 22.04 PHP 8.1 is patched, AlmaLinux covered its PHP streams including the retired ones, CloudLinux fixed every cPanel package from ea-php52 through ea-php85, and Remi ships fixes for 7.4, 8.0 and 8.1 on RHEL 8 and 9. Then the paid lifelines. TuxCare is rolling out fixes branch by branch, Freexian covers Debian’s old releases for a fee, Zend patched its long-term builds. And the orphans. Docker’s official PHP image ships no fix for 8.1 or older. Red Hat’s retired streams get none. Remi leaves 7.2 and 7.3 behind. PHP itself published minimal source backports for 7.4, 8.0 and 8.1 — a last resort, Patchstack notes, “not a restored support branch.”
Then there are the servers nobody’s counting. Hadrian’s advice for the week reads like a lost-and-found notice: find the forgotten PHP hosts now — end-of-life 8.1 and older, CMS stacks, appliances — name owners, book the change window. Legacy campaign sites, acquired subsidiaries, vendor appliances that never get upgraded on their own schedule. On Reddit’s PHP and technology forums, administrators of older PHP 7.x estates — a large share of the WordPress world — reported waiting on backported fixes from their Linux distributions, while others argued the unmanaged tail would take months. “Sucks for cybersecurity vendors who shipped their appliances using PHP without SELinux or AppArmor, of course,” Beaumont wrote. “Shodan dork ‘X-Powered-By: PHP/’ – a lot are on EOL versions with no patch. It’s also more hosts as not everybody lists their PHP version in headers.”
Hadrian logged exploitation attempts at scale on October 21, mostly through the session upload-progress path. The public proof-of-concept exploits aren’t yet reliable across different systems — Rapid7’s researchers managed a working exploit only under narrow lab conditions — but the firm’s conclusion was that the difficulty is a window to patch, not a reason to delay. For the 69%, there is no patch to hurry toward. PHP’s own guidance, relayed by Forrester, put it bluntly: “There are no complete mitigations, updating is the only safe choice.”
“The PHP situation will lead to a mass of incidents – it’s one of the biggest vulns in years,” Beaumont wrote. On Mastodon, a user posting as Philipp said the flaw “just grounded the Belgian school system provider,” with the platform down until the issue is dealt with. Germany’s BSI, updating its advisory on October 22, said it knew of no successful exploitation at scale yet.
And the “patched” side has its own clock. PHP 8.2 is in security-fixes-only mode. That ends on 31 December 2026.











