If your week went sideways last Tuesday night, you weren’t alone.
PHP2Shell, a pair of remote code execution flaws (CVE-2026-109618 and CVE-2026-109619) affecting PHP 5.4 through 8.5, was publicly announced on October 20—and not in the way anyone planned. A Hacker News post leaked the CVE identifiers ahead of the coordinated disclosure, which pushed the PHP security team into an emergency release. Fixed versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 shipped on October 21, both flaws carrying a 9.2 CVSS v4.0 rating and the ability to let an unauthenticated attacker run code on the server.
You’ve probably patched what you can. Now comes the harder part—working out what the incident means for how you run your business.
Do you really know where PHP lives across your client base?
Websites are the obvious place to look, and they’re not the whole story. The UK’s National Cyber Security Centre (NCSC) has warned that PHP can be embedded inside third-party products and appliances, which makes inventories and remediation messier. Think vendor portals, network gear admin panels, that legacy line-of-business app nobody has touched since 2019. Every PHP installation serving web requests is affected, whether it runs on PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, or LiteSpeed.
What’s your strategy for the long tail of dead branches?
Here’s the uncomfortable number. Mallory counted roughly 884,000 internet-facing hosts advertising PHP 8.1 or older on October 20—59% of the hosts that disclose a version at all. The PHP project no longer supports 8.1 and earlier, though the security team has published source backports for 7.4, 8.0, and 8.1, which Patchstack describes as a last resort.
And the clock is already ticking on the next cliff, since PHP 8.2 reaches end of life on December 31, 2026. Every client still running end-of-life PHP is a modernization project waiting to be scoped. Have that conversation now, while the headlines are doing the selling for you.
Who has the authority to pull the plug?
The official advice was blunt. The NCSC urged organizations to consider taking offline any system they couldn’t fix right away, and CERT-EU advised isolating internet-facing applications from public networks. Some took it literally: the University of Washington null-routed systems running vulnerable PHP versions rather than shutting them down, and Swiss host Cyon was reported to have taken several servers offline.
So, could you do that for a client at 2am without a three-person approval chain? If isolation authority isn’t written into your contracts and runbooks before an incident, you’ll be negotiating it during one. That’s the worst possible time.
Is your patch cadence built for AI-speed exploitation?
The timeline here should end the debate about monthly maintenance windows for internet-facing interpreters. Amazon Threat Intelligence spotted a PHP2Shell exploitation attempt dating to October 17, four days before public disclosure, and Cloudflare saw the first attacks hours before the update landed.
AI is on both sides of this. The flaws were found by Wiz Research, Calif, and OpenAI’s Codex Security team, and as one researcher put it, the window between disclosure and exploitation has shrunk from weeks to days, and now to hours. Your playbook needs a fast lane—interim mitigations (for CVE-2026-109619, disabling session.upload_progress.enabled and restarting every worker), WAF rules, and pre-approved emergency change windows that don’t wait for Patch Tuesday.
How are you telling the story to clients?
This wasn’t a niche advisory buried in a mailing list. Governments and companies worldwide took websites offline on October 21, and PHP runs on around 69% of all websites, according to W3Techs. Your clients’ boards have seen the coverage.
The MSPs who called clients first—”here’s what happened, here’s what we did, here’s what’s left”—banked trust this week. The ones who waited for the inbound “are we OK?” email spent the same effort and earned none of the credit. It’s also a good moment to clarify the responsibility split between you, the client’s hosting provider, and their web agency. When a shared or managed WordPress environment is involved, “who patches PHP?” shouldn’t have three different answers.
Bring these questions to MSP GLOBAL
PHP2Shell won’t be the last internet-scale flaw this year, and it probably won’t be the last one found by AI. The MSPs who come out ahead will be the ones who turn this week’s scramble into better discovery, clearer contracts, and faster response. Those are exactly the conversations happening at MSP GLOBAL—with peers who’ve just lived through the same week and vendors building the tools to make the next one easier.
Register for MSP GLOBAL 2027 now and join the people solving these problems in real time.
