ZoomEye data shows 2.65 million hosts still advertising end-of-life PHP 7.4

A dev.to analysis published on 28 October 2026 puts a number on the web's unpatchable PHP exposure: 2,650,830 hosts still return an X-Powered-By header identifying themselves as PHP 7.4, an end-of-life branch that will never receive a fix for the recently disclosed PHP2Shell flaw.

What was measured

The author queried the ZoomEye internet search index on 28 October 2026. A broad search for app="PHP" returned 111,072,293 matches, 22,706,573 of them on port 443. Narrowing to servers that volunteer their runtime, http.header="X-Powered-By: PHP" returned 46,709,646.

The version-specific counts are the notable ones:

• X-Powered-By: PHP/7.4: 2,650,830 hosts
• X-Powered-By: PHP/8.1: 530,860 hosts
• X-Powered-By: PHP/8.2: 796,916 hosts

According to the post, that ordering runs against intuition. PHP 8.2 is a supported branch that received a PHP2Shell patch, while 7.4 and 8.1 are end-of-life. Yet the branch that will never be patched appears more than three times as often as 8.2, and roughly five times as often as 8.1.

How far the numbers can be trusted

The dev.to post is explicit about what the method cannot see. The X-Powered-By header is optional, and hardening guides have recommended removing it for about a decade, so every figure above is a floor rather than a total. Servers that hide their version are invisible to this approach.

That blind spot skews the sample in a specific direction, the author argues: hosts that still broadcast a version tend, on average, to be the less carefully maintained ones. If anything, the dominance of 7.4 among disclosing servers understates the problem.

The post also cautions against reading host counts as organisation counts. A single shared-hosting platform can serve hundreds of thousands of domains from one runtime build, which is why the 111 million figure and the 46 million figure describe different populations: the first mostly signals that a web service exists, while the second identifies a subset willing to disclose its runtime.

The PHP2Shell backdrop

The October 2026 disclosure is what changed the stakes of a version banner. As the post summarises the branch situation, PHP 8.1 and earlier received source-code patches but no official binaries, and PHP 7.x and below received nothing at all. A host advertising 7.4 is not simply behind on patching; on that branch there is no patched state to reach.

Detection is the other half of the problem. The post cites a FreeBuf report from 22 October 2026 relaying CrowdStrike's findings that PHP2Shell exploitation leaves nothing visible in the application itself: the worker keeps running, the server answers with HTTP 200, and the only artefact is a fatal memory-limit error in the web server log. The author's conclusion is blunt — any environment that does not alert on that log line has no visibility into this class of attack.

What operators can do

For end-of-life hosts that cannot be upgraded, the playbook the post describes is short and, by its own admission, unpopular: take the host off the public internet, put it behind a proxy that terminates and inspects traffic, or retire it. Vendor backports close part of the gap — cPanel and CloudLinux shipped fixes for their PHP packages, covering a meaningful share of shared hosting — but they do nothing for a custom build sitting on a virtual machine someone created in 2019.

For asset owners, the author recommends turning the query inward: scan your own address space, collect the headers, and count how many distinct runtime versions you actually serve. Estates typically hold more versions than anyone expects, accumulated through acquisitions, side projects, vendor appliances and forgotten internal tools.

Why it matters

The count is one of the few concrete measures of how much of the public web runs software for which no fix will ever ship, and 2.65 million is the floor of that exposure, not its ceiling. It also reframes version disclosure: a runtime that announces its exact version on every response is handing attackers a targeting shortcut, where hardening checklists once dismissed the banner as a trivial information leak. The practical lesson is less about the global number and more about local inventory — the figure that should worry any organisation is how many runtime versions in its own estate nobody is responsible for upgrading. In a period when a pre-authentication runtime flaw can be turned into a working exploit within hours, an operator who does not know its own version distribution will respond slowly, and that delay is where the real cost sits.