When Taking Systems Offline Becomes the Safer Choice

On 21 October 2026, a number of public bodies chose to switch off their own websites for a few hours rather than keep them running while a serious software flaw was being fixed. This note looks at that choice: what was known at the time, what was given up, and why switching a service back on can be harder than switching it off.

01What happened

PHP is the programming language behind a large share of the world's websites. On 21 October its maintainers released security updates fixing two critical vulnerabilities, recorded as CVE-2026-109618 and CVE-2026-109619, across the supported release lines.^[1] The flaws, widely referred to as "PHP2Shell", could allow an attacker without a login to run code on an affected server or read sensitive memory.^[4]

The UK National Cyber Security Centre asked organisations to update. Its advice included a conditional line: where immediate remediation is not feasible, organisations "should consider taking the system offline until it can be fully mitigated".^[2][3] NHS England Digital issued a high-severity alert, and Switzerland's national cybersecurity office advised updating without delay.^[4][5]

Some organisations did go offline. Finland's government ICT centre took government websites down as a precaution.^[6] In Scotland, local reporting described at least seven of 32 councils and six health boards suspending their websites on the Wednesday, with many back the following morning.^[8] The BBC reported similar precautionary steps elsewhere.^[7]

02What the evidence does and does not show

It is easy to blur several different things together here, so it is worth separating them.

• An advisory is not a shutdown. The guidance asked organisations to consider going offline if they could not update. It does not tell us how many did.
• A precaution is not a compromise. The reports describe websites taken down to prevent possible harm. None of the sources used here states that these particular sites had been breached.
• A warning about likely attacks is not a record of attacks. Statements that exploitation is expected are assessments made at the time, not measurements.
• Not every outage that week was PHP. On 20 October, the day before, a power event at a Google Cloud facility in London disrupted services for several hours.^[9] That was a separate incident with a separate cause. Where a website was unavailable and no link to PHP was stated, this note does not count it.

We do not know how many organisations disconnected worldwide, how long each was offline, or whether every decision was necessary. We make no claim on those points.

03Why stopping can be the careful choice

Most of the time, keeping a public service running is the goal. The usual measure of a good system is that it stays up. Here, a number of operators reached the opposite conclusion for a short period: that a website which could not yet be trusted was more of a risk than a website that was briefly unavailable.

That choice makes sense mainly when the service can be paused without immediate harm. An information page for a council can be offline for an afternoon; people can phone, wait or visit. The judgement is much harder for services where a pause has direct consequences of its own. The sources do not tell us how individual operators weighed this, and we have not tried to guess.

04What is given up

Taking a website offline does not only remove a target. It also removes a channel. Public bodies often use their websites to tell people what is happening, so a precautionary shutdown can reduce the very information people look for during disruption. Other services that quietly depend on the same server, such as forms, booking pages or embedded tools, may stop at the same time, sometimes without the owners of those services expecting it.

This connects to a theme in Issue 04: when a system becomes reliable, other things grow up around it, and the cost of losing it can rise even though the system itself has not changed.

05The harder decision: switching back on

Deciding to stop is one decision. Deciding it is safe to restart is another, and it usually needs more evidence. An operator has to know which version is running, whether every copy and dependency has been updated, and ideally whether anything happened before the update. Shared hosting, older installations outside upstream support, and software bundled inside other products can all make that slower to confirm.^[1][5]

Reports that many Scottish sites were back the next morning suggest restoration was quick in those cases.^[8] We have not found reliable information on how long restoration took elsewhere, or what checks were carried out before services returned.

06How this differs from earlier work

Earlier Critical Dependencies work describes failures that happen to systems: Fragile Redundancy and Issue 02 look at backups that share hidden foundations, and Dependency Concentration at reliance on a few shared components. This note looks at an interruption chosen deliberately, under uncertainty, by the operators themselves. It sits closest to Operational Complexity, where a protective step in one place can have effects elsewhere, and to Issue 04.

07Questions worth keeping open

• Which public services can safely pause, and which cannot?
• When a website goes offline, how else do people get information?
• What does an operator need to know before it is confident enough to switch back on?
• Which services depend on a shared server without that being written down anywhere?