How Much of the PHP Web Cannot Take the PHP2Shell Patch?

The chart ranks every PHP version WordPress installs report, and the colour is the only thing that matters: did the PHP project ship a fixed release for that branch. PHP 8.3 and 8.2 dominate and both got one. PHP 7.4 is the largest branch that did not, at 15.9 per cent of all installs on its own, more than 8.4 and 8.5 combined.

The middle group is the part most coverage misses. For 7.4, 8.0 and 8.1 the security team published source backports but cut no release. Whether a site on 8.1 is exposed depends entirely on whether its distribution rebuilt the package, and the version string will not tell you either way. A fixed package keeps its old number.

So the honest label for the two lower groups together is “cannot get a patch from php.net”, not “unpatched”. And the top group is not “safe” either, because nobody publishes how many sites on a supported branch have actually updated since 21 October.

WordPress.org is one sample. It measures installs that check in for updates, which skews toward sites that are maintained. Run the same question past two other sources and the answer moves further than most of the figures quoted this week.

W3Techs, surveying sites where it can identify a PHP version, puts the share with no official patched release at 48.4 per cent as of 22 October 2026. The Joomla project’s opt-in statistics endpoint, covering 3,292,304 sites that volunteered, puts it at 93.2 per cent.

None of these is wrong. They are three different populations: everyone who checks in for a WordPress update, everyone W3Techs can fingerprint, and everyone who opted into Joomla telemetry. The spread between them is the finding, and it is why this post publishes all three rather than averaging into a single number that would describe no real population at all.

One branch dominates the unpatchable side of this chart. PHP 7.4 is on 15.9 per cent of WordPress installs, more than PHP 8.4 and 8.5 combined, and it stopped receiving security support in November 2022. Four years later it is still the second most common PHP version on WordPress after 8.3 and 8.2.

That is why the source backport matters so much here. The PHP security team published fixed source for 7.4, 8.0 and 8.1 without cutting releases, which hands the decision to whoever packages PHP for each host. Distributions with long-term support contracts rebuild it. Shared hosts on their own builds may not. Nothing in the version string distinguishes the two.

Below 7.4 the picture is simpler and worse. PHP 7.3 and everything older received no fix at any level, and that is 5.7 per cent of installs: a floor that no amount of vendor backporting will lift, because there is nothing to backport from.

For the 64.1 per cent of installs on 8.2 and above, the version string is a complete answer. PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 carry the fix, anything lower on those branches does not, and the number on the box is the number that matters. That is the entire population for which checking is simple.

For the 30.2 per cent on 7.4, 8.0 and 8.1 it settles nothing. A distribution that rebuilt its package from the published source shipped the fix without changing the version, so two servers reporting the identical 8.1 patch number can sit on opposite sides of this flaw. The answer is in the vendor’s package changelog, not in PHP’s, and there is no way to read it off the running process.

For the remaining 5.7 per cent there is nothing to check at all. No fix was produced at any level, so the question stops being whether a site is patched and becomes how long the branch has left. PHP 5.6 alone, out of security support since the end of 2018, is still on 1.3 per cent of WordPress installs, which is eight years of running a language version that has had no security releases to miss.