Offline on Purpose, and Saying Why

On Wednesday 21 October 2026, shortly before one in the afternoon, Dutch time, the websites of DigiD and MijnOverheid went offline. DigiD is the login Dutch residents use for their taxes, their health insurance and most of their dealings with the state. Nobody had broken into either.

The NOS liveblog of that afternoon reads like an inventory of a country. Within three hours the Dutch parliament, at least six hospitals, RTL’s website and app, and every Flemish government website had followed, along with local government sites in France and Finland. The bodies whose job is to advise everyone else did the same. The Dutch National Cyber Security Centre and the Autoriteit Persoonsgegevens, the data protection authority, took their own sites down, according to NOS, and Next found the French CNIL in maintenance at around half past twelve.

None of these sites had been breached, as far as anyone knew. They went dark because of two bugs in PHP, the language behind 69.3 percent of the websites whose server-side language is known, and because the fix would not exist until mid-afternoon.

Taking a site down before anything has happened to it is often the right call. From the outside, it looks exactly like a failure. That gap is where security has always been hardest to sell, and it is what this article is about.

The flaw was in the floor

Most web security news concerns an application: a plugin, a forgotten admin page, a weak password. This one did not. The two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, sit in PHP itself, in the way it handles running out of memory and in the state it keeps between requests. Both are rated 9.2 out of 10 and allow remote code execution without logging in, and the PHP security team rated Apache with mod_php the most exposed setup. Wiz, whose researchers found the flaws in August with teams at Calif and OpenAI and the help of AI models, put it plainly in its write-up: “even a simple ‘Hello World’ application running on an affected PHP version can be vulnerable”. The code had been there for more than a decade, and the flaws can also leak memory, which on a web server means passwords, tokens, API keys and certificates.

The fix was meant to ship on Thursday 22 October under coordinated disclosure: distributions receive the patch in advance, everyone publishes at the same hour, and attackers learn about the bug at the moment defenders can fix it. That plan lasted until Tuesday afternoon, as the PHP Foundation’s own account explains.

October 2026, UTC

17         first exploit attempt
20  15:00  CVEs leak, wrong score
    19:30  release moved up a day
    20:00  demo video out by mistake
21  03:02  Cloudflare rules go live
    07:41  a vendor ships the fix
    10:48  DigiD goes offline
    14:00  fixes for 8.2 to 8.5

Coordinated disclosure is a communication protocol, and in under seventeen hours it slipped three times, among people who do this for a living. The vendor shipped more than six hours early because, as its chief executive told The Register, “people were getting hit in advance”, which the PHP Foundation calls breaking the embargo. We will not referee that here. The point is simpler: if the experts’ own communication frays under this pressure, nobody else’s will hold without preparation.

Going dark is a decision, not a failure

For a few hours on Wednesday, the choice in front of many site owners was binary. Until the release there was no patch, and PHP was candid that its stopgaps “reduce exposure to specific attack paths but do not make an installation safe”. A proof of concept was circulating, and Cloudflare was already seeing attack traffic. For older versions the wait was longer: PHP 8.1 and earlier get no official releases, and W3Techs counts more than a third of PHP websites on version 7 or older.

The agencies said the same thing in their own registers. CERT-EU wrote that organisations “should consider isolating internet-facing resources from public networks until the fix is applied and verified”. CERT-FR asked for systems on unsupported versions to be isolated. The Dutch NCSC put going offline, on the strength of a risk analysis, next to patching as an acceptable answer, and in Japan the Prime Minister’s warning, as Jiji reported it, presented a temporary suspension as an effective way to reduce the risk. Note the last words of the CERT-EU sentence: applied and verified. Going offline is easy to start and hard to end, because somebody has to decide when it is safe to come back.

What makes that decision sound is not courage. It is a handful of facts: what the site holds, how PHP runs on it, who applies updates and how quickly, whether a fix exists for its version, and what an hour offline costs. Every one of them can be established on a quiet Tuesday. None of them should be researched at lunchtime on the day.

What the people on the other side see

Someone who tried to open MijnOverheid that afternoon did not experience a well-judged precaution. They experienced a government website that did not work. For the patient checking a hospital’s website, or the person trying to report sick through UWV, the most responsible decision of the day was indistinguishable from an outage.

Or from something worse. A maintenance page with no explanation leaves the visitor to fill in the blank, and during a security alert the most available explanation for a site that suddenly goes dark is that it has been hacked. ANSSI, the French national cybersecurity agency, warns about exactly this in its guide to cyber crisis communication: if an organisation “lies or refuses to communicate, its stakeholders may surmise that it has something to hide and draw their own conclusions”. A blank page is a refusal to communicate, whatever the intention behind it.

There is a second asymmetry, and it is the cruel one. A site that stayed online and unpatched that afternoon looked perfectly healthy. The one that went dark to protect its users looked broken. Done well, security is invisible. Done visibly, it looks like failure, unless somebody explains it.

What visitors want to know fits in four questions: is my data safe, do I have to do anything, when will it be back, and where will I hear more. On the third, the guide’s advice is the hardest to follow under pressure: “Do not commit to a specific recovery date at the beginning of the crisis”. Promise the next update, not the end. On the first, speak in the conditional, and say what you are doing to confirm it.

The page itself is short.

This site is offline on purpose.

A serious flaw in PHP, the software
behind much of the web, was announced
today. We have taken the site down
as a precaution while we install the
fix. At this stage, nothing suggests
that your data has been accessed. We
are checking.

You do not need to do anything.
Next update on this page at 16:00.

Seven sentences, no jargon, and no humour, on which ANSSI is firm: it “may be interpreted as a sign that the incident is not being taken seriously”. The page takes ten minutes to write on a quiet day. At noon on the day, with the phone ringing, it takes an hour and comes out worse.

Security was always the unpleasant part

None of this is new, and that is the uncomfortable bit. Security has always been the part of a project everybody agrees with and nobody wants to pay for: a line to negotiate down in a quote, the first saving in a maintenance contract, an update that changes nothing anyone can see. When it works, nothing happens, and nothing is hard to invoice. When it fails, it fails in public, so the instinct is to talk about it as little as possible.

Cormac Herley made the economic case about end users in a 2009 paper written at Microsoft Research: rejecting security advice “is entirely rational from an economic perspective”, because the burden is real and the benefit “largely speculative or moot”. The same arithmetic runs a maintenance budget. The update window and the awkward email to customers are certain costs. The breach that did not happen is invisible. On 21 October the invisible side of that bargain was on show for an afternoon.

It is worth noticing who communicated best that day. The PHP Foundation’s post calls its own slow handling of the bug “a structural failure, caused by both the security team’s decision process and its lack of resources”, adds “We won’t pretend otherwise”, then describes what will change. That is not a comfortable paragraph to publish while the whole industry watches. It is what the ANSSI guide calls controlled transparency: “Entities are not required to disclose everything, constantly and to everyone, but what information they do share must be truthful.”

Why it now comes first

Three things changed, and none of them is going back.

The first is the rate of discovery. Wiz says a single researcher, working with AI models, “completed in a week what previously would have taken a world-class team months of work”. The PHP security team has published 15 CVEs since 1 July. Old, widely deployed code is being reread quickly, by machines, and it will produce more days like this one.

The second is the time to exploit. Amazon’s honeypots recorded an attempt on 17 October, four days before disclosure, and Amazon’s write-up recommends measuring the response to this kind of flaw in hours, not in seven or thirty-day service levels.

The third is the law. Under Article 33 of the GDPR, a personal data breach must be reported to the supervisory authority within 72 hours of becoming aware of it, unless it is unlikely to put anyone at risk. Since 11 September 2026, the Cyber Resilience Act has also required manufacturers of software sold in the EU to report actively exploited vulnerabilities in their products, with a first warning due within 24 hours, and to inform the users affected. A website is generally not a product in that sense, but the direction is plain: talking about security, quickly and to the people concerned, is turning from a courtesy into a deadline.

Security comes first now, not because it became pleasant, but because being late became visible.

What to prepare before the next one

None of it needs a large team, only a few decisions taken before they are needed. This is the list we would want in place for any site, ours or a client’s.

Know what runs where. For each site: the PHP version, how it is served (mod_php, FPM or something else), who applies updates and how fast, and what the site holds. Include staging copies, containers and the software that quietly bundles PHP, for which the Dutch NCSC keeps a public inventory.

Agree on the shutdown in advance. Who may take the site offline, on what criteria, without waiting for whom. Write it down with the client. Like the break-glass path we described in August, it only works if it is fast: prepared on a quiet day, the decision takes a minute; improvised, it takes the afternoon.

Write the page now. Static, served by something other than what you are switching off, and worded for the people who will read it rather than for the engineers relieved to see it. Tell customers before the press, which is also the order ANSSI recommends: “start with informing your associates and clients/users”.

Treat “patched” as the middle, not the end. Investigate from the earliest known exploitation, the 17th in this case, not from the announcement. Rotate the secrets the server held, because the flaw can leak memory. Do not read silence as safety: as Rapid7 puts it, “The absence of relevant log entries is not proof that an installation is safe.” If personal data turns out to have been reached, the 72 hours run from the moment you know.

Say what happened, afterwards. What you did, why, for how long, and what you will change. A client who reads that note understands, often for the first time, what the maintenance budget was for.

Why a design studio publishes this

Because on 21 October, for a great many people, the interface of their government or their hospital was a maintenance page. It is read more carefully than any home page, by people who are worried, and it is rarely designed at all. We wrote in August that approval fatigue is a usability failure with a security outcome. This is the same idea, seen from the visitor’s side.

Service research has a name for the hope that a well-handled failure leaves customers happier than no failure at all: the service recovery paradox. A 2007 meta-analysis found the effect real for satisfaction, and nonsignificant for repurchase intentions, word of mouth and corporate image. Handled well, an incident can leave people satisfied. It does not make them more loyal. There is nothing to win on the day, only something to keep.

What it costs

Going offline on purpose has a price, and it is not small: lost sales, bookings or sign-ins, customers comparing you with a competitor who stayed up, and a fair chance that nobody would have attacked you that day, which makes the shutdown look like overreaction in hindsight. Preparing costs too: an inventory nobody asked for, a page nobody hopes to use, an hour of rehearsal that ships no feature.

We think the price is worth paying, on two conditions: the shutdown is short, and the explanation is ready. A precaution that lasts an afternoon and says so plainly is understood. One that lasts three days behind a blank page is remembered.

Nobody will thank you for the breach that did not happen. They will remember whether you told them the truth while it still could have.