You Can't Patch What You Haven't Inventoried
On October 21, the PHP project released fixes for two critical flaws, rated 9.2 out of 10, that let an attacker run code on a web server without logging in. Attackers moved fast: Cloudflare detected millions of exploitation attempts after disclosure, and what appears to be the first successful attack in the wild was reported on honeypot servers (The Hacker News). People are calling the pair PHP2Shell.
The fix is simple: update PHP. The hard part comes first. To update PHP, you have to know where it runs. If nobody can answer that quickly, it's a business risk, not just an IT task.
So answer this honestly. How many of your servers run PHP? Not just the public website. All of them: the intranet wiki someone stood up in 2019, the vendor appliance with a web admin page, the ticketing system nobody wants to touch. If your answer is a guess, this post is for you.
Most PHP in use is no longer supported
Qualys analyzed anonymized data from more than 10,000 customers and found about 167 million PHP installations. Of the 156 million where it could identify the version, about 73% sit on internet-facing systems, and 110 million (71%) run end-of-life releases that no longer get updates from the PHP project.
The other 44 million (28%) run supported releases and have a fix available. In the first 12 hours after disclosure, only about 199,000 installs had been patched.
One more number from the same report: in a single customer environment, 1,539 systems ran PHP and 25 were confirmed exploitable. You don't find 25 vulnerable servers among 1,539 by memory.
One caveat: these figures come from one vendor's own customer base, not an independent survey. The direction is still hard to argue with. Bitsight, working from the outside, counted nearly 37 million internet-facing systems running PHP or PHP-related software (The Hacker News).
Patching starts with knowing what you have
Patching has two phases. First you find every affected system. Then you update them. Most teams plan carefully for the second and improvise the first, and the first is where the exposure lives.
In a cloud account, finding things is mostly a query. Every subscription, VM and app service appears in a list someone can pull up. On-prem usually has no such list. The "inventory" is a spreadsheet that was accurate once, plus whoever remembers what got installed. That is where PHP tends to hide: self-hosted wikis, ticketing systems, old intranet apps, and any product that bundles its own PHP and never mentions it.
The same week showed this isn't only a PHP problem. Chrome and Firefox blocked several eMudhra certificate authorities after a researcher found their private keys were trivially guessable, and Chrome counted about 30,800 unexpired certificates tied to the affected root (The Hacker News). The first question for operators was the same one: which of ours are affected? Different problem, same dependency on knowing what you run.
Knowing the version is the start, not the answer
Inventory is the first step, not the last. PHP's own advisory says some Linux distributions and long-term-support vendors ship backported fixes, so you need to check your vendor for updated packages. The version number alone doesn't settle it, and the vendor advisory is the authority.
That cuts both ways. A server reporting an old version might already be patched, and your team burns a night on it. Or a server looks fine because someone assumed it was on a fixed release, and it isn't. Either way, the version is where the investigation starts, not the answer.
For PHP2Shell, fixed releases exist for PHP 8.2 through 8.5. PHP 8.1 and older no longer receive updates from the project, though its security team published minimal backports for 7.4, 8.0 and 8.1.
Two questions your inventory should answer first
You don't need a vulnerability scanner to start. You need a list that answers two questions for every server:
- Does it run PHP at all? The yes/no that most teams can't answer today.
- Which version, and is it still supported? This sorts the list into supported, end-of-life and "needs a vendor check".
Then add what only your team knows: whether each server is reachable from the internet, and who owns it. None of that needs alerting or scoring. It needs a list you can sort and filter on the morning an advisory lands.
What We're Building at Covene
On-prem monitoring is coming soon to CloudMonitor. It tracks server health, service status and logs, but not what software those servers run, and PHP2Shell exposed that hole.
So we're adding a server software inventory to it: what runs on each server and which version.
The scope is deliberately small. This is inventory only. It won't alert, score risk, or tell you a server is vulnerable, because as covered above a version number can't tell you that. It will give you the list to start from, and we think a trustworthy list beats a clever one.
We expect to open a beta by the new year, and likely sooner.
Want to know when CloudMonitor's on-prem monitoring is available? Email sales@covene.com or use the contact form here. Tell us which software you most need inventoried, and we'll build that list first.
