TL;DR: 4 days before disclosure, one public exploit attempt preceded PHP2Shell publication, according to WithSecure case work and vendor telemetry. The external attack surface then determines whether patching is a routine task or a prolonged hunt across unknown runtimes.
Editorial analysis by NHI Mgmt Group, based on content published by WithSecure: “72 hours of PHP2Shell: what MSPs learned”.
Key questions
Q: Why do CMDBs miss vulnerable PHP runtimes in real estates?
A: CMDBs miss vulnerable PHP runtimes because they usually track approved servers and software records, not every copied, bundled, or containerised interpreter actually running on hosts.
Q: How do self-compiled and embedded PHP installs change patching?
A: Self-compiled and embedded PHP installs break patching because they bypass package managers and standard update channels, so the owner must rebuild or replace the runtime rather than apply a simple repository update.
Q: What should security teams do first when a PHP web shell is found on an internet-facing server?
A: The first priority is containment.
Practitioner guidance
- Map external attack surfaces continuously Track every internet-reachable PHP runtime across customer estates, including staging, partner-built sites, containers and appliances, so discovery is always current instead of crisis-driven.
- Separate version checks by deployment model Run different checks for distro packages, self-compiled builds, container layers and appliance-embedded PHP because one scan will not cover all runtime sources.
- Prioritise public-facing remediation first Patch or isolate externally exposed PHP systems ahead of internal ones, especially when exploitation has already been observed or publicly reproduced.
Bottom line: PHP2Shell shows that patchability and discoverability are different problems, and the second one often decides how long exposure lasts.
Glossary terms: PHP2Shell, Embedded Runtime, Exploitation Window, Attack Surface
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
PHP2Shell turns asset inventory into a security control, not a reporting exercise. The flaw was patchable, but the exposed runtime problem lived outside the CMDB in partner-built sites, old staging systems and embedded appliance stacks. That is why discovery quality now determines exposure duration. In practical terms, the inventory that matters is the one that can answer where the runtime is, not the one that lists what was originally deployed.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What happens when public exploitation starts before disclosure?
A: When public exploitation starts before disclosure, attackers can target vulnerable systems before defenders have a patch, advisory, or vendor guidance. That shortens the safe response time and makes exposure dependent on detection speed, compensating controls such as virtual patching, and rapid isolation or upgrade of the affected service.
👉 Read our full editorial: PHP2Shell shows why patching fails without full exposure visibility