When the internet patches itself: inside the PHP2Shell response

On 21 October 2026, PHP’s security team pushed emergency fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10 on severity. Within about 24 hours, hosting providers, security vendors, national cyber agencies and agencies like ours had all converged on the same response, with no central authority telling anyone what to do.

That’s the bit worth sitting with. Nobody owns PHP. Nobody owns WordPress, which runs on it. And yet the whole ecosystem moved as one.

The thing is, that’s the argument for open source, in a single day. The code is open, so anyone can read the flaw, anyone can write the fix, and anyone can check it. Nobody had to wait for one company’s timetable or one company’s say-so. It isn’t flawless, as the long tail of old sites shows. But the speed of the response is hard to argue with.

What happened

PHP’s maintainers flagged the issue on 20 October, giving the world roughly a day’s notice before the fix landed. The flaws, nicknamed php2shell by researchers, allowed unauthenticated remote code execution, about as serious as it gets for anything running a web server.

Cloudflare had WAF protections live before public disclosure. National agencies, including the NSA and Australia’s ASD, issued advisories within hours. Security vendors like Qualys and Sophos published technical breakdowns almost immediately. And underneath all of that, thousands of smaller teams, agencies, hosts and freelance developers were doing the unglamorous work of actually applying the patches.

We were one of them.

How we spent the day

Our response started at 8am on the 21st, coordinated by Dmitry Romanovsky, our Technical Director, and Miles Gripton, our Operations Director.

The first job was checking on our hosting partners. Pressable, WP Engine and Nimbus Hosting all had fixes either live or in progress, so a good chunk of our client base was covered as soon as those providers rolled out. We spent the morning monitoring that process rather than duplicating it.

For the sites we build and run ourselves on lean, purpose-built Linode (Akamai) servers, our team patched directly.

Then there’s the part of the story that doesn’t wrap up in a day. A small number of our clients run bespoke sites on much older versions of PHP, sites we’ve encouraged them to modernise for years. Two of them turned out to be on older versions of PHP, that was out of support, when the current release is 8.5.

Those two were flagged around 9am, and Dmitry worked through to the early hours of the next morning putting protections in at server configuration level. Short-term mitigations were in place by the end of the day.

But they’re a stopgap. The proper fix is a code refactor, probably a few days of work, and when that happens depends on budget and appetite for risk. How exposed an unsupported version really is, nobody can say for certain. That uncertainty is exactly why the refactor matters.

For roughly 95% of sites we look after, the fix was straightforward. For the rest, it’s an honest, ongoing conversation about technical debt that’s now impossible to ignore.

Why this matters beyond the patch itself

It would be easy to write this up as just another CVE story. But the more interesting story is the coordination itself. Open source software doesn’t have a head office. There’s no single vendor who can mandate a fix and guarantee compliance, and no government that controls it. Instead, you get a layered, decentralised response: the language maintainers fix the core, infrastructure providers protect at the edge, hosts patch their platforms, and agencies like ours handle the long tail of custom and legacy sites.

It’s not a tidy system. But it works, and it worked fast.

The takeaway for site owners

If your site runs on current, well-maintained PHP and modern hosting, you were almost certainly protected within hours, often without needing to do anything yourself. If you’re running something older or more bespoke, this is a good moment to ask your agency or developer where you actually stand, and whether now’s the time to deal with that upgrade you’ve been putting off.

Two critical PHP vulnerabilities (CVE-2026-109618, CVE-2026-109619) were patched within roughly 24 hours of disclosure, thanks to a decentralised, uncoordinated response from PHP’s maintainers, hosting providers, security vendors, national agencies and agencies managing client sites directly. Most sites were protected automatically; older bespoke builds need individual attention.