PHP2Shell, two critical PHP flaws patched on October 21, 2026, often sits on supplier servers security teams don't own. Here's how an outside-in inventory of PHP versions answers "are we and our suppliers affected?" faster than a rescan, and what version data can't prove.
PHP shipped the patches for PHP2Shell, two critical remote execution vulnerabilities, on October 21. Applying them is the part of the response most security teams know how to do. Finding every place they need to be applied is harder, and many of those places are on servers you don't own.
PHP2Shell is two critical flaws in the PHP runtime that let an attacker take over a web server without logging in. Attackers were trying them within hours of the release. Versions 8.1 and older get no official fix.
The Dutch decision tells you how seriously some organisations took it. Taking a public website offline is a visible, unpopular call, and nobody makes it lightly. When public bodies decide an outage is cheaper than the risk of waiting for a patch, the rest of us should pay attention.
I've spent years building the tools that measure how far an organisation's digital surface reaches. This week was a good test of what that measurement is for.
Where PHP lives that nobody lists
Old PHP rarely sits on the main website. In scan data, it turns up on the assets nobody thinks of as theirs:
- a campaign microsite an agency built years ago
- a supplier's customer portal
- a WordPress install on a regional subdomain
- a control panel on a hosting box nobody watches anymore
Updating WordPress or another application doesn't touch any of this. The fix lives in the PHP runtime underneath, and whoever runs the server has to apply it. For a lot of the PHP that touches your business, that's a supplier.
So I'd frame the exposure around digital relationships. A supplier portal your customers log in to is part of your attack surface, whoever hosts it. The useful question is actually three questions:
- Are we affected?
- Are our suppliers affected?
- Where exactly?
Why an inventory answers faster than a rescan
A typical vulnerability scanner works forward from the advisory. A new flaw is disclosed, you scan your assets, and you wait for the results. For your own estate that takes time. For your suppliers' it often can't happen at all.
Passive discovery works the other way round. ThingsRecon had already mapped our customers' internet-facing assets and the suppliers they're digitally connected to, and recorded the PHP servers in that map with their versions. Those scans ran before the world had heard of PHP2Shell. When the advisory landed, the first answer was a look at the inventory. A new scan is only needed to confirm whether a particular server has since been upgraded.
On release day, one of our enterprise customers asked whether they were affected. They had the answer within the hour: no exposure.
What version data can and can't tell you
A version comes from what a server says about itself. Some admins hide it or change it. Some Linux distributions ship the PHP2Shell fix without changing the version string, so an old-looking version can already be patched. A visible version is strong evidence of where to look. The server owner, or a fresh scan of that server, confirms whether it's fixed.
In practice, that means the inventory turns a large estate into a short list quickly, and the verification work goes only where it's needed.
Not every PHP server matters equally
Once you have the list, the order matters. A supplier server that handles your customer logins sits much closer to your core systems than an agency's forgotten microsite, even if both run the same old version.
That's the idea behind our metric Digital Proximity (patent pending). It ranks suppliers by how directly their exposure touches your core systems, so the short list comes back in the order you should work through it.
What I'd look at this week
- Filter your inventory for PHP, across your own assets and your suppliers'.
- Sort by branch. Anything on 8.1 or older has no official fix, so it goes to the top. The patched versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
- Rank by proximity. Start with the suppliers whose PHP sits closest to your core systems.
- Confirm with the owner. Ask each supplier when their fixed build ships, and treat the version you see as a lead to check.
- Rescan to verify. Once a supplier says they've upgraded, a targeted scan of that server confirms it.
PHP2Shell is the kind of event that tests whether you understood your digital relationships before you needed to. The organisations that answered quickly this week did the mapping weeks ago. The next flaw like this will ask the same two questions, and the inventory is what lets you answer them.
