MSPs Hold the Keys: Patching Your Own Systems and Every Client's After PHP2Shell
If you run a managed service provider or IT support business, you are not just another organisation with a website to patch. You hold remote access, administrator credentials and management tooling for every client you support. That makes you one of the most valuable targets an attacker can find, and the PHP2Shell vulnerabilities disclosed on 21 October 2026 are a timely reminder of why your patching has to be faster than anyone else's.
For the background on the two PHP flaws, the government websites that went offline and how quickly attacks followed, read our main article: PHP2Shell and the Cyber Essentials 14-day patching rule. This piece is about what it means for MSPs specifically.
Why attackers target MSPs first
This isn't speculation. In 2022 the UK's NCSC joined its Five Eyes partners in a joint advisory for managed service providers and their customers, warning that malicious actors continue to target MSPs and describing them as a major target precisely because so many businesses rely on them. The logic is simple: MSPs are granted privileged access to customer networks, so compromising one provider can open the door to all of its clients at once.
Put bluntly, an attacker who breaks into one client gets one client. An attacker who breaks into you gets the lot.
Your clients' contracts are going to change
The NCSC's guidance on responding to active exploitation of vulnerabilities tells organisations to make sure their critical suppliers and managed service providers are contractually liable to rapidly fix internet-facing vulnerabilities that are being exploited in the wild. The same guidance gives a timeline: a known-exploited, internet-accessible flaw that can be attacked automatically and gives full control should be updated within 24 hours.
Expect clients, insurers and procurement teams to start asking you to commit to that in writing. MSPs that can already show a same-day emergency patching process will win that conversation.
Patch in this order
1. Your own estate first
Before you touch a single client, secure the systems that give you access to them:
Remote monitoring and management (RMM), PSA and documentation platforms. If any of these are self-hosted, check whether they run on PHP and update them before anything else.
Client portals, ticketing systems and your own website. Anything public-facing that runs PHP is in the firing line.
Hosting and control panels. Plesk, for example, warns that its own interface uses a separate PHP build that has to be patched alongside the PHP versions serving websites.
Appliances. The NCSC notes that products may bundle PHP, and points to an NCSC-NL inventory of affected software.
2. Internet-facing client systems
Next, every client website, web application and portal you host or manage. Work through them by exposure, not alphabetically. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, restart the PHP service, and confirm the running version afterwards.
3. Everything else
Internal servers, development environments and anything you didn't know was there. Shadow IT is where emergency patching usually fails.
Unsupported PHP is your problem too
Plenty of client sites still run PHP 8.1, 7.4 or older. The PHP project's fixes only cover supported branches. Some hosting vendors are shipping fixes for older builds, but if you're relying on that, you need it confirmed in writing. Under Cyber Essentials v3.3, software that no longer receives security fixes has to be removed or moved out of scope. An out-of-support PHP version on a client's in-scope server will fail their assessment.
What this means for your clients' Cyber Essentials
The Cyber Essentials requirements are explicit that all accounts your client owns are in scope, even when an MSP uses them, and that where services are managed externally, the client must be able to confirm the technical controls are being met. In practice that means your clients will be asking you:
When was the update released, and when did you apply it?
Are automatic updates on wherever possible?
Which systems are running unsupported software?
Keep a dated patch log per client. When they come to complete their self-assessment, you'll save them, and yourself, hours. It also helps with the separate MSP headache of unique credentials and shared admin accounts.
Our recommended standard for MSPs
Cyber Essentials allows a maximum of 14 days for high and critical updates. For MSPs, we'd suggest a tighter standard than we give anyone else:
Your own internet-facing and management systems: same day for critical updates, as a matter of policy.
Client internet-facing systems: within 24 hours when there's active exploitation, and within 7 days for all other high and critical updates.
Everything else: never beyond 14 days.
These are our recommendations rather than scheme rules, but given how quickly PHP2Shell was attacked, we think anything slower is hard to defend.
Get your own house certified
Clients increasingly want to see that their IT provider holds Cyber Essentials itself. If you're thinking about how to get Cyber Essentials for your MSP, or want to support clients through their assessments, see our page for IT partners, or talk to us on 0333 339 0383.
Comments