By Adrian Cheek, Senior Cybercrime Researcher

Two critical vulnerabilities in PHP have put renewed attention on a familiar operational question: how many internet-facing PHP services are running versions that no longer receive upstream security fixes?? We examined existing internet-scan records to measure the PHP versions that services disclose to the public internet. The result was 2,220,231 service records across 224 countries. Nearly three quarters advertised a PHP branch no longer supported by the PHP project.

That finding does not mean 1.6 million servers are confirmed vulnerable to PHP2Shell. It shows how large the older-branch population is, and why a simple instruction to install the latest PHP release does not cover every environment. Some older PHP versions continue to receive security fixes through operating-system vendors; others are embedded in products whose update path depends on a manufacturer.

Key Findings About PHP2Shell

• Nearly three quarters of version-disclosing PHP services run unsupported branches. Of 2,220,231 service records, 1,613,623 (72.7%) advertised a branch outside upstream support, while 606,608 (27.3%) advertised PHP 8.2 to 8.5.
• A banner is not a patch verdict. Distributions and appliance vendors can backport fixes without changing the reported version. Five distribution-associated version strings alone account for 418,288 records (18.8%) whose true patch state cannot be determined from the header.
• A handful of old version strings dominate. PHP 7.4.3 and PHP 7.4.33 together make up 21.3% of all records, and the 18 most common exact strings account for 46.9%.
• PHP is not just on websites. A regional sample found PHP on remote-access, storage, access-control, VPN, and building-automation interfaces, often on nonstandard ports such as 81, 8080, and 8888 that a ports-80-and-443 inventory would miss.
• Fixed-release banners were barely visible at first. About two hours after the fixed releases were published, one platform showed eight matching records and the other showed one host. This is a baseline for visibility, not a patch-adoption rate.loo

What We Measured

Using previously collected records from two commercial internet-scanning platforms, Flare focused on the X-Powered-By HTTP response header, which can disclose a PHP version when the expose_php setting is enabled.

The unit of measurement is an internet-facing service record, not a unique server or website. A single host listening on several ports can contribute multiple records. Conversely, PHP deployments that suppress the header, sit behind intermediaries or fall outside platform coverage are not included. The figures describe the observed version-disclosing population, not every PHP installation on the internet.

The four supported branches were measured directly. The older-branch total is the remainder after those records were subtracted from the observed population.

Why the 73% Finding Matters

The PHP project supplied emergency fixes for CVE-2026-109618 and CVE-2026-109619 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Public technical guidance describes the flaws as capable of unauthenticated remote code execution, with risk extending to PHP deployments that serve web requests. That urgency makes the age of the installed PHP estate an immediate operational concern.

Of the version-disclosing services in Flare’s dataset, 606,608 advertised one of the four upstream-supported branches. The remaining 1,613,623 advertised versions outside the PHP project’s maintenance window. PHP 8.1 and 8.0 together accounted for 188,138 records; another 1,425,485 advertised versions below PHP 8.0 or fell into the residual category outside the measured PHP 8 branches.

This finding does not mean 1.6 million servers are confirmed vulnerable to PHP2Shell. An unsupported upstream branch is not necessarily an unpatched machine. Distributions and appliance vendors can backport security changes without replacing the upstream version number. Conversely, an old device whose supplier no longer issues security updates may need to be isolated, replaced or retired. The external header cannot tell those situations apart.

The Most Common PHP Versions are Surprisingly Old

Two strings alone made up 21.3% of all observed records: PHP 7.4.3 appeared 246,881 times and PHP 7.4.33 appeared 225,216 times. Across the dataset, the 18 most common exact version strings represented 1,040,475 records, or 46.9%.

Those strings have different meanings. PHP 7.4.33 is the final upstream PHP 7.4 release. PHP 7.4.3 is also associated with Ubuntu 20.04 packaging, where security fixes can be backported while the reported upstream version stays the same. Treating every banner as an exact measure of installed security patches would obscure that distinction.

418,288 Records that a Version Check Cannot Resolve

Five version strings associated with operating-system distribution packages accounted for 418,288 observed service records, 18.8% of the entire dataset. These records form an uncertainty category: the same advertised version might exist on a host that received maintained vendor security updates or one that missed years of patches.

For example, 28,442 records advertised PHP 8.1.2, a string associated with Ubuntu 22.04. PHP 8.1 is outside upstream maintenance, but Ubuntu may continue providing security backports under its own support policy. By contrast, Ubuntu 20.04 moved beyond standard maintenance in 2025; continued coverage depends on the applicable maintenance arrangements and installed package revision. Neither case can be settled from the HTTP header.

This is why external attack-surface discovery and internal patch verification must be joined. A response header can identify where to look. Package-manager evidence and vendor advisories are needed to establish what is actually installed and fixed.

PHP is Present in More than Conventional Websites

A regional sample from one US state reinforced another practical issue. Across two scanning platforms, the sample comprised 101 and 89 hosts respectively, and showed 54 PHP version strings. The platforms’ service labels included:

• 40 remote-access entries
• 34 login-portal entries
• 16 network-attached-storage entries
• 11 VPN entries
• eight physical-access-control entries
• eight building-automation entries

Categories can overlap and the sample is not representative of the global population.

The PHP header appeared on ports including 81, 82, 250, 557, 1443, 3333, 8080, 8081, 8888, 9021 and 9022. A security inventory restricted to ports 80 and 443 could overlook interfaces that administrators use to reach appliances and other equipment.

17 hosts in the regional sample advertised PHP 5.1.6, the same web-server version and an identical vendor-default TLS certificate associated with a consumer storage platform. That clustering is consistent with a shared firmware lineage, although it cannot establish the product’s current patch availability. It illustrates why remediation sometimes involves product support and replacement decisions rather than an ordinary application upgrade.

What the First Patch Snapshot Showed—and Did Not Show

In a scanning-platform snapshot examined roughly two hours after the reported fixed releases were published, we found eight records advertising the new release strings on one platform: five on PHP 8.4.27 and three on PHP 8.5.12. The second platform showed one matching host.

This is a baseline for when fixed-release banners became visible in the scanning data, not a global patch-adoption rate. Commercial scanning platforms refresh records at different times, so observed timestamps and actual host updates cannot be equated. Repeating the queries under consistent collection rules may help track later visibility.

What Defenders Can Do Now

• Identify PHP installations from internal asset and package inventories, including development, disaster-recovery, and administrative environments. Use internet-visible banners as discovery leads, not proof of vulnerability.
• For PHP 8.2–8.5, deploy the corresponding confirmed security release: 8.2.35, 8.3.36, 8.4.27, or 8.5.12, subject to your vendor’s deployment guidance.
• For older branches, check the distribution or appliance manufacturer’s advisory and package revision for backported protection. Where support is absent, prioritize migration, isolation, or replacement.
• Include management interfaces and nonstandard web ports in exposure reviews. The regional sample found PHP on storage, access-control, remote-access, and building-management services.
• Do not mistake removal of the X-Powered-By header for remediation. Disabling expose_php limits disclosure but does not change the underlying code or its patch state.

What These Numbers Mean

PHP2Shell is a time-sensitive vulnerability event, but the data points to a longer-lived maintenance issue. In the observed population, older PHP branches substantially outnumber upstream-supported ones. Many of these deployments may be maintained through downstream packaging, and some may not be vulnerable. Yet the public banner alone cannot show which are protected, which are unsupported by their actual vendors, or which can be updated promptly.

The practical lesson is to treat exposed version data as a starting point for verification—not as a patch verdict—and to include the appliance and management-interface estate when measuring PHP risk.

Methodology and Scope

We analyzed already-published records from two commercial internet-scanning services. Counts refer to service records disclosing PHP versions through HTTP headers and are subject to data freshness, scan coverage, repeated ports, proxy behavior and banner accuracy. The 224-country distribution reflects platform geolocation. This research did not test hosts for PHP2Shell or establish compromise. The regional appliance observations are illustrative, not a global estimate. All numerical exposure findings are from Flare’s internal measurement; external sources below support vulnerability and patch descriptions.

We ran the same inventory across our own estate, since the measurement above shows that a version banner is a starting point rather than a record of patch state, and that holds for any interpreter an organization depends on.

External Technical References

PHP2Shell operational guidance, NCSC Netherlands (October 21, 2026): https://github.com/NCSC-NL/php2shell

PHP2Shell technical analysis, Wiz Research (October 21, 2026): https://www.wiz.io/blog/php2shell-php-rce

Emergency patch reporting (October 21, 2026): https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/