Why we took the websites of almost all our clients offline for a while

On October 21, one well-known website after another went offline, from DigiD and the House of Representatives to municipalities and hospitals. Even the National Cyber Security Center displayed only a notification. No hack had been confirmed anywhere. Yet all those organizations took themselves offline. As long as there was no update, in principle any website running on PHP could be compromised, and being unavailable for a few hours is the lesser risk. We made the same decision. We called all our clients to ask if we could temporarily take their sites offline. Virtually everyone said yes right away.

Nearly three-quarters of all websites run on PHP, including many of the ones we build. Visitors never see it: it lies beneath a website just as a foundation lies beneath a house.

There were two vulnerabilities in that foundation, now known as php2shell. Anyone who knew how to exploit them could take over a web server without physical access. The vulnerabilities were so complex that almost no one could turn them into a working attack. As a result, no one realized how serious they were, and a solution was never found.

The fact that the bugs were found this year anyway is thanks to AI. In August, two security firms stumbled upon them independently, both with the help of AI models that scanned PHP’s source code. Whereas such a flaw could previously only be understood by a handful of specialists, AI now did a large part of the legwork.

According to the researchers, AI is thereby changing the economics of hacking. A vulnerability that used to be too complex to exploit is now a viable target: AI can adapt an attack to different PHP versions and configurations, and takes over much of the specialized work. This applies to researchers who responsibly report such vulnerabilities, as well as to attackers who do not.

On October 20, even before the planned announcement, news of php2shell leaked. PHP moved up the release of the fix to October 21. It later turned out that Amazon had already detected an initial attack attempt on October 17. So someone was already aware of the vulnerability; that’s why we’re reviewing our logs back to that date.

For us, the decision was simple. A site that displays a maintenance page for a few hours costs visitors. A site that is compromised can result in data loss, reputational damage, and weeks of recovery work. The National Cyber Security Center also advised taking systems offline if necessary.

When we managed the hosting ourselves, the sites went offline quickly, with a message displayed to visitors. With external hosting providers, it sometimes took longer; they were just as busy that day. As soon as the patches were released at 3:43 p.m., we updated and restored the sites one by one. Even then, we called every customer as soon as their site was securely back online. On a day like that, clear communication is just as important as the technical aspects: customers need to know what’s happening, why, and when it will be over.

By around 11:00 p.m., virtually all sites were back online. For most, the outage lasted between two and a half and nine hours. The last customer deliberately chose to err on the side of caution and went live again the next morning at 7:30 a.m.

The fact that the vulnerability was in PHP says little about PHP itself. Java, JavaScript, and .NET have all had similar vulnerabilities in recent years, prompting urgent updates to be installed worldwide.

One reason PHP is targeted is that it’s so widely used: the more websites run on a language, the more researchers and attackers focus on it. It’s a mature language that’s actively maintained; a solution was available just one day after the news broke. What matters is how quickly you can patch things up when things go wrong.

An incident like this shows how the internet works: a chain in which each link depends on the others. Our suppliers also run on PHP and had to partially shut down their own systems.

We’re going to further reduce our dependence on that chain. We’re drafting a plan to quickly take sites offline, ensuring that all sites run on a supported version of PHP, and making arrangements with suppliers for emergency updates.

There’s an uncomfortable side to this story: the same AI that helps us build faster also makes attacks easier. As a result, emergency updates like this one will be needed more often.

No model could answer the questions that mattered on October 21. Which customer is running on which server? Which hosting provider should we call? That required people who know the systems and are willing to make a decision within a few hours.

AI makes building easier, but it doesn’t make keeping a platform secure any easier. Moments like these will happen more often, and that’s when you’ll need a partner who knows your platform. That remains the job of an agency—and it remains a job for people.