The PHP flaw of 21 October: who was watching your website?

On Wednesday 21 October, DigiD, the login service for Dutch government websites, went offline. So did MijnOverheid, along with the websites of the Dutch House of Representatives, RTL Nieuws and Tweakers (NOS, 21 October 2026). The cause was a flaw in PHP: two critical bugs in the programming language that around 70 percent of all websites run on. At Your Tech Club, several client projects run on PHP. That Wednesday we went through them one by one: what is the risk here, and what does the client want?

The update is out and things seem to have calmed down. Still, one question remains that I heard more often this week than "am I safe?". The question is: who was actually on call?

What exactly is the PHP flaw of October 2026?

The flaw consists of two critical vulnerabilities in PHP itself, known as CVE-2026-109618 and CVE-2026-109619, or PHP2Shell for short. An attacker can use them to run code on your web server without logging in. PHP released the fix on 21 October at around 4 pm: versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

The bugs were given a severity score of 9.2 out of 10. According to Sansec, they are in every PHP version since 5.4, so they've been there for well over ten years. That is why organisations took their sites offline as a precaution, before the update was even available.

One thing hasn't quite sunk in for many business owners. The flaw wasn't in WordPress, your theme or a plugin. It was in the software on the server. So a WordPress update fixed nothing. Only a new PHP version on the server did.

How was the PHP flaw discovered?

By AI. Security firm Calif found the first flaw using OpenAI's GPT-5.6 Sol and reported it to PHP on 11 August. Wiz found both bugs independently, partly using Google's Gemini 4 Argon. Disclosure was planned for 22 October, but the details leaked earlier.

To me, this is the most important part of the story. The bugs sat in the code for more than ten years without anyone noticing. With AI, researchers found them within a few weeks. Wiz even says one researcher did in a week what a top team used to take months over. That claim comes from a company that sells security software. The direction is right, though.

Attackers use AI too. A hacker going by the name KillaBoi cracked a test server through the flaw last week and won about $2,000 in bitcoin for it. According to BNR, it took him almost 20 hours, a lot of expertise and AI.

So flaws are being found faster, and by both sides. OpenAI, which helped with the discovery, expects such findings to increase sharply in the coming months. What else AI can do, you can read in my piece on GPT-6.1 Terra. For website management, it mainly means you need to know, for each site, what it runs on and who decides about it. That's no longer an IT detail.

Do I still need to do anything about the PHP flaw?

Yes, unless you know for sure that the update is on your server. Ask your hosting provider or agency which PHP version your website runs on and whether it was updated on or after 21 October. If your site runs on PHP 8.1 or older, plan an upgrade. Those versions no longer get regular updates from PHP itself.

Go through these points, or have your agency do it:

1. Check your PHP version. In WordPress you'll find it under Site Health, in the server information.
2. Check the date. If the build date in phpinfo is 21 October 2026 or later, the patch is in place.
3. Look ahead. PHP 8.2 stops getting security updates after 31 December 2026. Plan the move to 8.3 or 8.4 now.
4. Don't install fix plugins. A plugin can't close a flaw in PHP itself, and snippets like that can actually break your site.
5. Ask whether anyone has checked the logs. Amazon saw the first attack attempts as early as 17 October, four days before disclosure.

There's good news on that last point too. Sansec first predicted large-scale abuse within fifteen minutes of the update. A day later it revised that, because the public attack scripts don't work against a standard PHP installation. The Dutch National Cyber Security Centre said the same on 23 October: the chance of large-scale abuse is smaller than expected. Small isn't zero, though.

Who is responsible if your website has a security hole?

You are, as the owner of the website. In practice, though, the work sits with several parties. Your hosting provider patches the server, your agency maintains the code and the integrations, and you decide who to call when things go wrong. On shared hosting, the provider did most of the work this time. If you had your own server, it was down to you.

Dutch hosting providers such as Versio and Yourhosting closed the flaw centrally on their servers. Customers on shared hosting didn't have to do anything themselves. But many business websites don't run on shared hosting. They sit on their own server, a VPS or with a cloud provider, and nobody patches those automatically.

The questions we got that day varied a lot. Some larger projects went offline until the update was out; that was a deliberate choice, made together with the client. Others stayed online, with the risks in view. In the end we kept everything safe.

That's my point. A website without a maintenance agreement isn't a saving, it's a gamble. Usually the gamble pays off. On 21 October, for many businesses, it nearly didn't.

What should a website maintenance contract include?

At least four things: who keeps the server and the PHP version up to date, within how many hours someone closes a critical flaw, how you hear about it, and where a backup is kept that is stored separately from your server. A response time on its own says little. You want a promise about fixing, not just about calling back.

What I wouldn't do: move your website to another platform in a panic. A site built in Next.js or a Shopify store doesn't run on its own PHP server, so this flaw didn't hit them directly. But every platform has its own flaws. Choose on maintenance, not on last week's news.

How do we handle it? Not with a single tool. Our maintenance clients have an SLA, with several monitoring tools running underneath. External services send an alert as soon as something is off. We also follow the news about security flaws and watch for unusual activity on the sites. Those sources come together, and clients see them in their own dashboard. If something is critical, the right person gets an alert straight away on their phone or by text, depending on the SLA. A website agent is one part of that, not a replacement.

How do you know whether your website is properly looked after?

The next flaw will come. I'm not saying that to scare you; OpenAI and Wiz say so themselves. The only question is whether you'll know within an hour who is working on it.