PHP2Shell leaves millions of servers on unsupported PHP
PHP’s emergency security release fixes supported branches, but hundreds of thousands of internet-facing hosts still advertise unsupported versions.
PHP’s PHP2Shell emergency patch has fixed the supported branches, but a huge number of internet-facing hosts still advertise an end-of-life PHP version with no official upstream release available. That gap matters because the two critical flaws can enable unauthenticated remote code execution before an application’s own code runs. 1
Why the patch gap is so large
A Shodan count published by CybelAngel on 20 October found about 884,000 internet-facing hosts advertising an unsupported PHP version. That was roughly 59% of the approximately 1.5 million hosts in the sample that revealed a version number. The count is a banner survey, not a tally of confirmed vulnerable websites: shared hosting can put many sites behind one address, while about 740,000 additional hosts did not reveal their version. 2
CybelAngel’s breakdown put roughly 369,000 hosts on PHP 5.x, 329,000 on PHP 7.x, and 186,000 on PHP 8.0 or 8.1. PHP 8.1 reached upstream end of life on 31 December 2025; PHP 8.0 ended support in November 2023, and PHP 7.4 in November 2022. PHP published no numbered fixes for PHP 5.6 or 7.3 and older branches. 1
That does not mean every machine showing an old number is automatically exposed. Linux distributors can backport security fixes without changing the upstream version string. Ubuntu 22.04, for example, patches its PHP 8.1 package through the normal security channel, while PHP 7.4 on Ubuntu 20.04 needs Ubuntu Pro. Administrators need to check their distribution’s changelog against both CVE IDs rather than relying on the banner alone. 2
What PHP actually fixed
PHP’s official security notice says PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities that can allow unauthenticated remote code execution. The PHP team identifies PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed installations serving web requests as potentially affected, with the risk highest for mod_php in the demonstrated exploit path. 1
The official fix is an infrastructure update, not a WordPress, Drupal or other CMS plug-in update. PHP’s own guidance says administrators should move to a fixed supported branch immediately. For branches that cannot move at once, distribution or long-term-support backports may exist, but those need to be confirmed with the vendor rather than assumed from the version string. 1
The practical order is straightforward: identify every internet-facing PHP runtime, check the package changelog and the version actually serving requests, apply the fixed package, restart PHP-FPM or the web server, and then look for signs of compromise. That last step matters because patching removes the vulnerability but does not remove an attacker who entered before the update. Checks should include unexpected PHP files, new administrator accounts, unusual outbound connections and unfamiliar child processes launched by the web server. 2
Why the old branches are the real problem
The supported release line has a clean upgrade path. The long tail does not. A PHP 5.x or 7.x server may be embedded in a shared-hosting stack, tied to an old control panel or supporting an application that has never been tested on a current runtime. Those constraints explain why the exposure count can remain high after the emergency release, but they do not make an unsupported internet-facing runtime safe.
CISA’s advice, as reported by Notebookcheck, is blunt: organisations that cannot update, or that still run unsupported PHP 8.1 or earlier, should take PHP-based systems offline until they can patch or upgrade. PHP 8.2 security support ends on 31 December 2026, so even an immediate move to 8.2 is a short runway compared with 8.4 or 8.5. 3
The related gaming-sector coverage of PHP2Shell is focused on emergency maintenance across game services. This story covers the wider technology problem: how many hosts may be left on branches where the normal upstream patch route no longer exists, and why a green-looking version number can be misleading. That distinction matters for shared infrastructure, suppliers and forgotten applications as much as it does for a site’s public homepage.
Our opinion
The headline number is alarming, but the useful warning is more specific: organisations should stop treating PHP’s version string as a complete security answer. The first question is whether the distribution has backported both fixes; the second is whether every PHP runtime exposed through a supplier, control panel or forgotten subdomain has been checked. If the answer to either question is unknown, the sensible position is to isolate the service while the inventory and upgrade work happens.
PHP’s official release gives supported users a direct route out. The harder work is finding the unsupported systems that nobody thinks of as PHP servers any more. That is where the remaining risk sits, and where administrators should spend their next hour.