When PHP2Shell landed, the UK’s official fallback was to switch things off, and dozens of public services did. Few organisations had decided in advance who makes that call, what people see instead, or what has to be true before a service comes back. With AI speeding up how flaws are found, they’ll be asked again.
On Thursday 22 October, the tech minister Baroness Lloyd of Effra told the House of Lords that 32 government services were unavailable and four more were partially unavailable. An attack wasn’t the cause. The disruption “has resulted largely from precautionary measures taken to protect systems”, she said, adding that the government was “working very carefully with departments to restore the services safely and securely.”
The day before, as we covered in PHP2Shell Was Found With AI, PHP had shipped emergency fixes for two critical flaws that let an attacker run code on a web server without logging in. By that afternoon the websites of Edinburgh and Oxford councils and the Metropolitan Police were down, and Bristol, Lambeth, and Barnet councils’ sites were showing errors. The Office for Budget Responsibility took its website offline, and peers raised disruption at the DVLA and police services.
Most of the UK’s PHP2Shell downtime wasn’t caused by attackers. It was chosen. That isn’t a criticism. Switching off was in the official advice, and for many it was the right call. The question for everyone else is whether, on 21 October, it would have been a decision or a scramble.
Switching Off Was in the Official Advice
The NCSC’s guidance, published on 21 October, set out a clear order of play. Find every system running PHP, starting with the ones facing the internet. Update to a fixed version. If you can’t, apply the PHP Foundation’s temporary mitigations. And if those aren’t possible or would take too long, “you should consider taking the system offline until it can be fully mitigated.”
The advice across Europe ran the same way. CERT-EU told organisations that couldn’t patch to isolate internet-facing applications from public networks until a fix was in place. The Dutch NCSC took its own website down as a precaution, and public bodies in Finland, Denmark, France, Germany, and Belgium followed. PHP’s own advisory left little room for anything else: “no complete mitigations, updating is the only safe choice.”
For a public body running an internet-facing PHP application it couldn’t patch that day, the off switch was defensible. Code execution without a login, on a server that holds residents’ data, is about as serious as web vulnerabilities get, and Amazon had seen an exploitation attempt four days before the fix existed. The advice was sound. What it couldn’t do was make the decision for you.
Precautionary Downtime Is Still Downtime
A website taken down to protect it is just as unavailable as one an attacker took down. In Edinburgh, local press reported that residents were left without access to council services and online payments, with no clear end date. The council said the site was down for “essential maintenance” and that it was waiting on an update from its provider. For a lot of organisations, that’s the real position: the patch, and so the restore, sits with someone else.
It wasn’t only a public-sector problem either. The NCSC sent 50,000 warnings to businesses and other organisations, and private companies rarely announce when they switch something off.
There’s a commercial side as well. Insurance Business described PHP2Shell as “close to the scenario cyber underwriters have long modelled”, and noted that whether business interruption cover responds to a precautionary shutdown with no breach “depends on the policy wording and the waiting period.” Underwriters will also ask how quickly you updated once the fix was out. A shutdown you choose can cost as much as one forced on you, and your insurer won’t necessarily treat it the same way.
Four Decisions to Make Before the Next One
The organisations that handled 21 October calmly weren’t the ones with the boldest instincts. They’d already answered four questions.
Who can switch it off? Name the person with the authority to take a public service offline, and a deputy for when they’re on a plane. Agree the threshold in advance, for example a critical flaw that can be exploited without a login, on an internet-facing system, with no fix or tested mitigation available within a set number of hours. When the threshold’s written down, the call takes minutes. When it isn’t, it takes a meeting.
What do people see instead? “Offline” shouldn’t mean a browser error. Between full service and switched off sits a rung the official advice doesn’t spell out, a degraded mode. That might be a static page served from separate infrastructure that tells people how to pay, report, or get help by phone. It might be a read-only version of the site, or the one vulnerable feature taken down while the rest stays up. Each of those has to be built and tested before you need it.
Who holds your patch? List every public service, the runtime it depends on, and who can actually update it: your own team, your hosting provider, your agency, or a SaaS vendor. For anything you don’t patch yourself, you need a contracted response time measured in hours and an out-of-hours contact who’ll pick up. Otherwise your restore date is whatever your supplier says it is.
What has to be true to switch it back on? “Safely and securely” needs a definition. At minimum, the fixed version is confirmed on the running server, which means checking the build or package rather than trusting the version number it reports. The NCSC’s advice to “assess the system for any evidence of compromise prior to your upgrade or mitigation” has been followed. And a named owner signs the service back on. Without exit criteria, a precautionary outage drifts from hours into days.
Every rung on that ladder needs an owner and a way back, agreed before the incident rather than during it.
This Won’t Be the Last Time
PHP2Shell was found by a researcher working with an AI model, then found again weeks later by a second team that was also using AI. On the day PHP shipped its fixes, Node.js patched a remote code execution flaw credited to OpenAI’s Codex Security, and OpenAI expects findings like these to “increase sharply in the coming months”. PHP has since disclosed a third, narrower flaw in the same family, which it’ll fix in a regular release.
Two things follow for continuity planning. Critical flaws in widely used software are going to arrive more often. And the gap between a fix shipping and attackers using it has all but gone: PHP2Shell was being probed four days before the patch and drew millions of attempts within a day of it. The off switch belongs in your continuity plan, next to power cuts and cloud outages, not in an incident channel at four in the afternoon.
Where to Start This Month
Write the threshold down. Add a precautionary-shutdown scenario to your incident response plan, with the decision owner, the deputy, and the criteria for pulling a service.
Build one fallback page. Pick your most-used public service and give it a static holding page, hosted away from the application, that tells people what to do instead. Then check you can switch to it in minutes.
Ask your suppliers for a date. For every runtime you don’t patch yourself, get the supplier’s response commitment for critical vulnerabilities in writing. If there isn’t one, you’ve found your biggest continuity gap.
Read your policy wording. Check whether your cyber or business interruption cover responds to a shutdown you chose, and what the waiting period is, before you need to claim.
Rehearse 21 October. Run an hour-long tabletop exercise on the PHP2Shell timeline. Who’d have made the call, what would people have seen, and when would you have switched back on? The gaps show up fast when the scenario is one that really happened last week.
Q&A: Taking Services Offline for PHP2Shell
Should we have taken our website offline for PHP2Shell?
If an internet-facing system ran an affected PHP version and you couldn’t update it or apply the temporary mitigations quickly, the NCSC’s advice was to consider taking it offline until it could be fully mitigated. If you could patch within hours, patching was the better option. Either way, check the system for signs of compromise, because exploitation attempts started before the fix was released.
What did the NCSC advise organisations to do about PHP2Shell?
Identify every system running PHP, starting with internet-facing ones, and update to a fixed version. If you can’t, apply the PHP Foundation’s temporary mitigations, and if those aren’t possible or would take too long, consider taking the system offline. The NCSC also advised assessing systems for evidence of compromise before upgrading or mitigating.
Does cyber insurance cover a precautionary shutdown?
It depends on your policy. Whether business interruption cover responds to a shutdown with no breach depends on the policy wording and the waiting period, so check both with your broker before you need to claim.
What should a website show while it’s offline?
A planned holding page, served from separate infrastructure, that explains the service is temporarily unavailable and tells people how to pay, report, or get help another way. A browser error or a blank page leaves people with nowhere to go and pushes them onto your phone lines.
How do we decide when it’s safe to bring a service back?
Agree the exit criteria in advance: the fixed version is confirmed on the running server, the system has been checked for signs of compromise, monitoring is in place, and a named owner signs the service back on.
Working Through This With Vertex Agility
As an AI-native transformation consultancy, we treat security-driven downtime as a continuity problem with an engineering answer. Our Business Continuity & Disaster Recovery programme covers the business impact analysis, recovery objectives, communication plans, and incident exercises that turn a switch-off into a planned step. Our Security Healthcheck gives you a fast read on where your exposure sits.
If you’d like to know how your organisation would have handled 21 October, our free Downtime Defence Audit scores your disaster recovery, resilience, backups, incident response, and monitoring in about three minutes. It’ll show you which of these decisions you haven’t made yet.