On the morning of Wednesday 21 October 2026 we made a call that no web company wants to make. We switched off our clients' websites. A critical vulnerability, now known as PHP2Shell, had been found in PHP, the language that runs most of the web, including most of the sites and systems we look after. A fix was due that afternoon, but until it arrived any affected site could be taken over. We phoned every one of our clients, and every one of them agreed that their site should go offline until it was patched. By 15:55, everyone was back up and running on a fixed version of PHP.
This is what happened, why we made that decision, and what we think it means for anyone whose business runs on PHP.
What was PHP2Shell?
The vulnerability has become known as PHP2Shell, and the researchers who found it have published a plain-English explanation at php2shell.com. It is a pair of related flaws in PHP itself, tracked as CVE-2026-109618 (memory corruption when PHP runs out of memory) and CVE-2026-109619 (stale data left behind from an earlier request). PHP's own advisories are GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp.
Together they allowed an attacker to run their own code on a server running PHP, with no login needed. That is about as bad as it gets: someone who can run code on your server can read your database, steal customer data, change your site, or use your server to attack other people. The researchers also showed that the flaws could be used to read passwords, API keys and other secrets straight out of the server's memory. Because the bug is in PHP rather than in any one website, even a perfectly written site was exposed.
It affected every version of PHP from PHP 5 onwards, so practically every PHP site on the internet was exposed, from WordPress and Drupal to Laravel applications like the ones we build. PHP rated it 9.2 out of 10 for severity. The details leaked earlier than planned, so the patched versions were not expected until 15:00 UK time (14:00 UTC). That left most of a working day in which sites were vulnerable and the details were circulating.
Why we switched sites off
There were really three options:
- Leave everything running and hope. Attackers move quickly once details are out, and "hope" isn't a security policy.
- Leave everything running and restore from backups if something goes wrong. Backups would let us rebuild a site, but they can't un-steal data. Once customer data has left the building, restoring from yesterday's backup doesn't help.
- Take the sites offline until they can be patched. A few hours of downtime is inconvenient, but it is predictable and it is recoverable.
With a severity of 9.2 out of 10, rated by the PHP project itself, we chose option three. We then rang each client to explain the risk and the plan. We started calling at 07:30 UK time, all of them agreed, and by 08:10 every site was off. The UK government's advice at the time was also to take affected services offline until they were patched.
What about the workarounds?
Through the day we kept checking whether anything would let us bring sites back early.
- Cloudflare published new firewall rules aimed at the attack. They were welcome, but Cloudflare didn't claim they gave complete protection, and as a small provider we weren't prepared to put clients back online on a partial fix.
- Configuration changes were suggested on Hacker News as a way to block the attack. A PHP core developer confirmed that the only real fix was a patched version of PHP.
Now that the fix itself is public, we can see that it changes how PHP recovers after running out of memory, right across the language and dozens of its extensions. No setting could have switched that off. Had we relied on the workarounds, our clients would not have been safe.
As soon as the patched packages were available we installed them, checked each site, and switched them back on. PHP published the fix at 15:00 UK time, and we were live again with every client by 15:55.
Were we right to switch off?
Not everyone thought so at the time. Some people felt that switching sites off was an overreaction, and that a "potentially vulnerable" server isn't the same as one that is actually being attacked. A day later, we're confident it was the right call.
Attacks started within an hour of the fix escaping. (UK times below are BST, which is UTC+1.) The PHP project had planned to publish the patches at 15:00 BST. According to the PHP Foundation's own account, one software distributor broke the embargo at 08:41 BST that morning by publishing builds containing the fix, more than six hours early. Security firm ELLIO, which runs a network of decoy servers to watch attackers at work, recorded the first attack attempt at 09:36 BST, just 55 minutes later and five and a half hours before the fix was public. By that evening they had seen one attacker go from a first probe to a working exploit in 48 minutes, and automated attack bots had added the flaw to their rounds. Our clients' sites had been off since 08:10, half an hour before the embargo was even broken, and stayed off for all of it.
The setup we use was directly in the firing line. PHP confirmed that one of the two flaws could be exploited against Apache with mod_php using default settings, before any of the website's own code runs. That is a very common way of running PHP, and it's one we use.
The world took it seriously. The UK government's cyber security advice was to take affected services offline until they were patched, and we had already done it before that advice was published. By the next morning the story was the BBC's lead item, with a live feed running. A vulnerability that gets that kind of response is not one to sit out and hope.
We made the decision with what we knew at the time: a severity score of 9.2 out of 10 from the people who make PHP, no patch for several hours, and no way to know exactly how the attack worked. Knowing what we know now, we'd make the same decision again.
Why we could act quickly
Being small helped
We're a small company, and our clients are mostly small businesses, many of them local to us in Sheffield. Many have been with us for over a decade. That meant we could do something a large provider couldn't: pick up the phone to every single one of them before most people had got to work.
That wasn't luck. We keep our clients' mobile numbers, and they have mine, for exactly this kind of situation. A critical security problem shouldn't wait for an email to be read or a support ticket to reach the top of a queue. In forty minutes we had spoken to everyone, explained what was happening, and had their agreement to switch off.
It helps that our clients trust us. Nobody demanded proof that their site was about to be attacked. They understood that a few hours offline was a small price compared with a data breach, and they let us get on with it. We're very grateful for that.
We run the hosting ourselves
We were able to make this call, and to do it site by site, because we run our clients' hosting ourselves. We know which server each site lives on, which version of PHP it uses, and we can stop and start it ourselves without opening a ticket with someone else.
Not every web supplier can do that. Some resell hosting from another company and have no way to take a single site offline without turning off everything, or have no way to patch until their host gets round to it. Many sites are also running on old, unsupported versions of PHP, which simply don't get security fixes at all. If that's you, a day like this one becomes much harder.
It also helped that our clients' systems are on supported versions of PHP. Getting the fix in was a routine update, not an emergency upgrade.
Thank you to the people who package PHP
Most Linux servers don't get PHP straight from the PHP project. They get it from packages built by a small number of people. For Debian and Ubuntu that's Ondřej Surý, and for Red Hat-based systems it's Remi Collet. Both turned around patched packages on the day. As far as we can tell much of that work is voluntary, and Remi was on holiday at the time.
A large part of the internet relied on two people doing that work quickly and well. You may know the famous XKCD cartoon: all of modern digital infrastructure, balanced on one little project that "some random person in Nebraska has been thanklessly maintaining since 2003". On 21 October it stopped being a joke. The real-life version gets only two details wrong: Ondřej isn't from Nebraska, and he's been packaging PHP since 2005, not 2003.
If your business depends on PHP, it's worth considering supporting these people, for example through Ondřej's Patreon or the PHP Foundation.
Is this the end of it?
Possibly not. When AI tools were recently turned on the Linux kernel, a wave of serious bugs followed. We expect the same scrutiny to turn up more problems in PHP, perhaps soon. We hope we're wrong, but the sensible thing is to be ready:
- Know what you have. Which sites and systems run PHP, which version, and where they're hosted.
- Stay on supported versions. A site on an end-of-life version of PHP won't get a patch when the next one hits.
- Make sure someone can act. Your supplier should be able to patch, or take a site offline, within hours, not days.
- Have a "big red button" plan. Decide in advance who makes the call to switch things off and how clients and customers will be told.
Does your site run PHP?
If you're not sure whether your website or system was affected, or whether it's been patched, ask your supplier now. If you don't have one, or they couldn't answer, we can help. Our Systems MOT checks what you're running and where the risks are, our legacy support service brings older PHP systems onto supported versions, and our managed hosting is the setup that let us act on the day.
Get in touch and we'll tell you where you stand.