PHP2Shell and the FTSE 250 (coverage-led)

We answered "where does the FTSE 250 run PHP?" in an afternoon. The data was already there.

On 20 and 21 October, two vulnerabilities were disclosed in the PHP engine itself (CVE-2026-109618 and CVE-2026-109619, together known as PHP2Shell). Fixes shipped in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.1 and everything older gets no fix at all.

This post gives you a sector-wide picture of PHP exposure across 244 FTSE 250 companies, as of 23 October 2026: how much PHP there is, how little of it says what version it runs, and what that means for finding it in your own estate.

Observatory, our attack surface platform, continuously monitors the public-facing estates of organisations including the FTSE 250, recording every host we see, what it's running, and when we saw it. So when PHP2Shell landed, we didn't have to go looking. We'd been looking all along.

What we found

Across the public internet-facing estates of 244 companies on our FTSE 250 list, as of 23 October:

• 48% expose at least one host that identifies itself as running PHP: 654 hosts in all.
• 56% expose PHP or software built on it, such as WordPress, Drupal, Laravel or Roundcube.
• 92% of those hosts give no version number at all.
• Of the 54 that do, 25 are on a branch that will never be fixed, 27 are below the fix on a supported branch, and 2 had already moved to the fixed release within days of it shipping.
• 20 companies (8%) have a host self-reporting a vulnerable version.

Three things to bear in mind. These figures reflect each host as we last saw it, not as it is today. A reported version isn't proof of vulnerability: Debian, Ubuntu and Red Hat backport security fixes without changing the version string, so "below the fix" means self-reports a version below the fix. And hosts are hostnames; several can sit on one server, so 654 is an upper bound.

What it took

Every figure above is a query over observations Observatory had already collected. Here is the shape of that data.

Depth: 3,879 PHP observations, from four different signals. A PHP host rarely announces itself. We recognise PHP four ways: the X-Powered-By header a server sends, a technology fingerprint of the application, the PHPSESSID cookie a PHP session sets, and the product running on top (WordPress, Drupal, Plesk, Roundcube, Laravel, Joomla, Moodle and more). Only the first two carry a version. Relying on them alone would have cut our 654 hosts to 54. The other 600 are the finding.

The fourth signal matters more than it sounds. 21 companies showed no sign of PHP itself, only of software built on it. A search for "PHP" alone would have missed every one.

Granularity: down to the patch level. Seven hosts were exactly one release short of the fix. Two had already applied it. That level of detail is what separates "you have PHP" from "you have PHP 8.4.26 on this host, last seen on 7 October, and the fix is 8.4.27".

‍Speed: minutes. Once we'd worked out what to ask, the sweep across all 244 companies ran in under seven minutes of database time. The companies we only started tracking a month ago were already in it, 300 hosts between them. And because every observation is dated, we could tell which hosts had been seen recently and which needed checking before anyone acted on them.

Why this matters more than the numbers

Every security team asked the same question last week: where do we run PHP? The teams that answered fastest were the ones with the most to look through: broad, dated, well-attributed observations of their own surface, gathered continuously, in one place they could query the moment the advisory landed.

For them, PHP2Shell was a lookup. For everyone else, it was a project: working out which hosts to check, checking them one at a time, and trusting whatever each one chose to reveal that day.

That's the real lesson of the FTSE 250 numbers. Not that 48% of large UK companies run PHP (of course they do), but that 92% of their PHP is invisible to version matching, and the only way to see it is to have been looking, in several ways, for a long time before you needed to.

What to do this week

1. Find every PHP host you expose, versioned or not, including hosts that only show PHP through the applications they run.
2. Patch supported branches to 8.2.35, 8.3.36, 8.4.27 or 8.5.12.
3. Plan the exit from PHP 8.1 and older. There is no fix coming for those branches.
4. Check your Linux distribution's advisories. Debian, Ubuntu and Red Hat often backport security fixes without changing the reported version, so a host that looks vulnerable may already be patched.
5. Ask what your inventory could answer tomorrow. If the next disclosure is in a framework, a CMS or a mail client rather than a language, would you be running a lookup or starting a project?

Where Observatory comes in

Within days of the disclosure, we could see, for the FTSE 250, where PHP was running, which hosts gave a version, and which had been seen recently enough to act on. That’s the part that matters. The window between a disclosure and the first exploitation attempts is short, and most of it gets spent not on patching but on finding what to patch.

Having that picture already in hand collapses the finding. The hosts that need attention first are visible on day one, the ones that need checking are marked as such, and the team’s time goes on closing the exposure rather than searching for it. Reduce the looking, and you reduce the time an organisation is open to exploitation.

That’s what the FTSE 250 numbers show. The organisations that close their exposure fastest aren’t the ones that react fastest. They’re the ones that already know what they’ve got.

‍