Fortirix/ Research

threat-intel · php · attack-surface

PHP2Shell: What Fortirix's External PHP Inventory Reveals

All statistics are aggregate and anonymized, drawn from Fortirix’s own external scan data. Nearly all of the 9,912 in-range hostnames were observed before the October 21 patch, most of them in the three months before it; a small number come from scans run between October 21 and October 26. Figures were compiled on October 26, 2026 (see Methodology).

In scans taken almost entirely before the PHP2Shell patch, one in four of the root domains we monitor had at least one internet-facing hostname advertising an affected PHP version: 9,912 hostnames across 172 root domains. That is 99.3% of every hostname we see advertising PHP. And two-thirds of the supported-branch matches sit on a single point release, PHP 8.2.30.

On October 21, 2026, the PHP project disclosed CVE-2026-109618 and CVE-2026-109619, two critical remote-code-execution flaws nicknamed “PHP2Shell.” CISA issued an alert the same day, the major CDNs pushed emergency WAF rules, and several European governments took sites offline as a precaution. Within days Cloudflare was reporting exploitation attempts in the millions, researchers had caught working shells on honeypots, and on October 26 CISA added both CVEs to its Known Exploited Vulnerabilities catalog.

What these numbers are, and aren’t. They count hostnames whose own responses advertised a PHP version inside the published affected ranges, mostly observed in the three months before the patch. They don’t show what those hosts were running on disclosure day, and they are not proof that a given host is unpatched or exploitable: a version header can’t reveal a backported fix that keeps the old version string, or which server setup the host uses. The details are in the Methodology section.

Why the version matters more than usual

Many PHP CVEs only apply under a condition a scanner can’t see. 2024’s mass-exploited CVE-2024-4577 only fires on Windows hosts running PHP-CGI. The 2026 SOAP use-after-free, CVE-2026-6722, only matters if the SOAP extension is loaded and handling attacker input. For those, a version match is a weak signal.

PHP2Shell is different in where the flaws sit: both are in PHP’s core request handling, not in an optional extension or a platform-specific code path. 109618 is in the out-of-memory cleanup path, and 109619 involves request-scoped global state that can go stale between requests. The PHP project says all PHP installations serving web requests are at risk, and both CVEs are rated CVSS v4.0 9.2 (Critical). Exploitability still depends on the deployment: the project demonstrated an unauthenticated exploit against Apache with mod_php that fires before any application code runs, and it considers PHP-FPM susceptible but hasn’t shown a complete FPM exploit.

So for PHP2Shell, these version matches identify candidates for urgent verification. They don’t establish exploitability.

The breakdown

Across the most recent observation of each hostname on our platform (more than 700 root domains), here is the affected population by what remediation is possible:

PHP populationHostnamesRoot domainsRemediation path
Supported branches 8.2–8.5 (fixed in 8.2.35, 8.3.36, 8.4.27, 8.5.12)7,523143Point-release update
End-of-life branches 5.4–8.1 (no upstream fixed release)2,389116Backport (vendor or self-applied), or migrate off the branch
Pre-5.47324Outside both published ranges

Nearly all of these observations were taken before the patch existed, so this is effectively the starting line: almost none of these hostnames could have been running a fixed release yet. Hosts may have changed versions since their last scan, in either direction.

One point release, two-thirds of the findings

After disclosure we added both CVEs to the platform’s findings, so every supported-branch host in range now carries a per-host Critical finding for each CVE: 7,638 hostnames across 146 root domains. By branch:

Share of PHP2Shell findings by PHP branch (7,638 hostnames; compiled October 26, 2026)
PHP 8.271%
PHP 8.324%
PHP 8.45%
PHP 8.51%

The striking number is a single point release: PHP 8.2.30 accounts for 5,041 hostnames, about two-thirds of all PHP2Shell findings. One plausible explanation is large managed-hosting or distribution-default fleets sitting on the same release. If that’s right, a handful of platform updates could close thousands of findings at once. We haven’t verified who operates these hosts, so treat it as a hypothesis. A re-scan could show whether these hostnames change versions together, but attributing that to a provider would take more evidence.

The end-of-life tail

The harder problem is the 2,389 hostnames across 116 root domains on branches that will never get an upstream fixed release. Some branches in this group have been unsupported for the better part of a decade.

Not all of them are necessarily exposed. PHP published source-level backports for 7.4, 8.0 and 8.1, and Linux distributions and hosting vendors ship patched builds that keep the original version string, which a header can’t distinguish. Hosts on 5.4–7.2 are also in range only for CVE-2026-109619, since NVD’s range for CVE-2026-109618 starts at 7.3.0. But for every host without a backport, the options are isolation, decommissioning, or migrating to a supported branch.

On our platform these hosts get a single Critical end-of-life finding rather than a per-CVE match, because there is no fixed release on their branch to point to. 2,535 hostnames across 122 root domains have that finding open. Combined with the 7,638 PHP2Shell findings, 10,173 hostnames have an open finding related to this exposure.

The question to ask about your own attack surface

On the day a critical RCE in software you run everywhere is disclosed, how quickly can you list which of your internet-facing hosts run it?

For the estates on our platform, the answer was already on file. The PHP version every hostname advertised had already been recorded, mostly within the three months before disclosure, and within days it became a per-host finding with a severity attached. That gives a security team an existing inventory to guide verification. How quickly each team acts on it is something this data doesn’t measure.

If you’d like to see your own external PHP inventory the way we’d report it, with supported and end-of-life branches separated, request a scan of your domain.

Methodology & limitations

  • Non-intrusive observation. PHP versions are read from response headers (Server, X-Powered-By, X-PHP-Version) returned to ordinary HTTP(S) requests; we never send exploit payloads. Hosts that suppress version headers aren’t counted, which pushes totals down. Backports push them up: Debian, RHEL and other vendors ship security fixes without changing the advertised upstream version, so some in-range hosts may in fact be patched. We count what the host advertises, and label it as such.
  • Version match ≠ exploitability. Fortirix did not test exploitation or investigate whether any host was compromised. CVE-2024-4577 additionally needs Windows + PHP-CGI, and CVE-2026-6722 needs the SOAP extension handling attacker input. The PHP advisories distinguish between server setups (an exploit was demonstrated on mod_php; PHP-FPM is considered susceptible but undemonstrated), and a version header doesn’t reveal the setup. “End-of-life” is a lifecycle fact, not an exploitability claim.
  • Observation dates. Each hostname contributes its most recent completed observation. Nearly all of the 9,912 in-range hostnames were observed before the October 21 patch, most in the three months before it and the remainder as far back as December 2025. A small number come from scans run between October 21 and October 26. Figures were compiled on October 26, 2026. Quote every number with its as-of date.
  • Findings vs. observations. Finding counts are open findings on the platform. A finding closes when a re-scan shows a fixed version. A header alone can’t detect a backported build that keeps the old version string, so in that case the owner marks the finding as a false positive with a justification, and an admin reviews it before it closes. An open finding reflects the last observation, not a confirmed current state.
  • Unit of counting. A “hostname” is a distinct hostname observed serving HTTP(S); wildcard DNS and shared platforms can map many hostnames to one deployment. Root domains are used as a proxy for organizations; one organization may own several.
  • Scope. The universe is the estates we scan, not a random internet sample; percentages describe this population.
  • Anonymity. All statistics are aggregate counts; no customer, domain, host, IP, or organization is named or described in any identifying way.

Sources & further reading

Our per-host figures come from Fortirix’s own scan data; the external context below is sourced to public reporting.