When PHP2Shell was published on October 21, the first question in most MSP channels was not “how do we patch?” It was “where is it?”
The patch was the easy part. Finding every place that needed it was not.
Lesson 1: The inventory was not the environment
The CMDB listed what you deployed. The estate also held what partners built themselves: a campaign site from three years ago, a forgotten staging server, a booking tool installed by a cousin. Any of them can be reachable from the internet.
Lesson 2: Knowing the version is its own task
Distribution packages follow the vendor’s schedule, so sometimes you wait. Containers and self-compiled builds need separate checks. And PHP embedded in appliances may not show up in a package scan at all.
Lesson 3: Order matters
Internet-facing first, internal second. Pressure rose as public reproductions appeared. National cyber authorities, including CISA, the Canadian Centre for Cyber Security and the UK NCSC, issued alerts, and security vendors reported exploitation attempts. Amazon recorded one on October 17, four days before disclosure. In the AI era, the time between disclosure and exploitation keeps shrinking, so speed matters. Detection helps while you patch: WithSecure™ Elements EDR detects abuse of the vulnerability.
Lesson 4: Say what you are doing, and what it costs
Partners want to hear three things: what is affected, when it will be done, and how the work is priced. Be open about all three. Emergency patch work is real work, and a clear explanation protects the relationship. The MSP who knows first what runs at a partner is the one who gets the call next time.
Before the next one
A spreadsheet built during a crisis is out of date the next week. What works is continuous mapping of the external attack surface, so the answer to “where is it?” is already waiting.
