The PHP flaw of 21 October: five lessons, and why security starts in the office

What happened on 21 October?

On Wednesday 21 October 2026, the organisation behind PHP reported two serious flaws in the core of the software. PHP is the programming language that runs a large part of all websites, from web shops to government sites. With the flaws, someone could run their own code on a server without logging in. PHP gave both flaws a severity score of 9.2 out of 10. All versions from PHP 5 onwards were vulnerable.

Example code that showed how the flaw worked was already public. The NCSC (the Dutch National Cyber Security Centre) had not yet seen any abuse. But it asked organisations to install the update as soon as it was available.

Many organisations took no risk. As a precaution, DigiD, MijnOverheid, the website of the Dutch House of Representatives and the website of the NCSC itself, among others, went offline. Hospitals such as Haaglanden MC and St. Antonius also took their sites offline for a while. At 16:00 the update came. After that, the sites slowly came back online.

The NCSC stressed that this was not an attack, but a fault in the software: "a flaw woven into the software, and that can happen". But the NCSC warns of a long aftermath. With similar flaws, attackers kept looking for systems that were not updated for a long time.

Us too: this is how we handled it

it-label.com also runs on PHP. So on 21 October we did what we also advise others to do. First, we checked which of our websites and systems were vulnerable. Until the update was there, we watched the servers more closely. When the update became available, we installed it the same afternoon. Then we checked that everything worked correctly again and that there were no signs of a break-in. There were none.

We do not share more details about our systems, and we do this on purpose. That is also a lesson: how your security works exactly does not have to be public.

Five lessons from the PHP flaw

1. Know what you have. On 21 October, many organisations did not know right away which systems use PHP. Do not think only of the website, but also of the customer portal, the intranet, the web shop and the management screens of devices. If you have no overview, you also do not know what you must update.
2. Make sure you can update fast. Who may install an update? Who has the access? How long does it take? Record this before you need it, also if your website is with a hosting company or web agency.
3. Have a plan for the day of the flaw. Who decides if a site goes offline as a precaution? Who informs customers and staff? DigiD and the hospitals showed that going offline for a while can be a wise choice.
4. Build your security in layers. A fault in one layer must not open everything. For example, a web server should not have easy access to the files, the accounts or the office network.
5. The update is not the end. Check that nobody got in before the update was there. And stay alert: the NCSC expects that attackers will look for systems that are not updated for months.

Software is only one layer: cyber security starts in the office

With the PHP flaw, all attention went to software. That is logical, but it is only part of the story. An attacker does not always have to come in through the internet. Sometimes the door of the server room is the easiest way in. We wrote about this before in The door to your server room: physical security and Why physical IT security is indispensable for cybersecurity.

So also ask yourself these questions:

• Is the server room or patch cabinet locked? And who has the key or the access card? Often it turns out that cleaners, installers or other tenants can also get in.
• Are the Wi-Fi access points protected? Are they placed so that a visitor can pull out a cable and connect their own laptop? Is there a reset button that anyone can press?
• Is the guest network separate? Guests, the office network and other tenants should each have their own network.
• Where does the internet connection come in? And who can get to that place? In multi-tenant office buildings, tenants often share a technical room.
• Are the building systems separate? Access gates, cameras and climate control should not be on the same network as the laptops.
• Is there a cyber security policy? Who is the owner? Does it say who does updates, who has access to which systems, which agreements there are with suppliers and what you do with a flaw like the one of 21 October?

You cannot see the answers to these questions from your desk. Someone must look on site.

Where IT-Label helps

With the IT-Label Security Audit, a specialist looks on site at the security of your Wi-Fi, your network equipment, the server room, the place where the internet connection comes in and the separation between networks. You get a report with what goes well and what can be better. Read more in How secure is your office IT? New: the IT-Label Security Audit

The IT-Label also shows how a building was delivered digitally: from the connection and the cabling to the technical rooms. This way, owners and tenants know where they stand, and who is responsible for what.

Frequently asked questions

Was my website also vulnerable?

If your website or one of your systems uses PHP, it was probably vulnerable. All versions from PHP 5 onwards were affected. Ask your web agency or hosting company if they installed the update, and if they checked that nobody got in.

My website is with a hosting company. Do I have to do something?

Often the hosting company installs the update. But that is not always the case, for example with your own server or an old package. So ask them, and record who is responsible for updates in the future.

What is a cyber security policy, and do I need one?

A cyber security policy is a document that says how your organisation deals with digital security: who is responsible for what, who has access, how updates are done and what happens in an incident. A short version is also useful for a small company. Then, on the day of a flaw, everyone knows what to do.

Does the Security Audit also look at my website?

No. The Security Audit looks at the IT on site: Wi-Fi, network equipment, server room, connection and separate networks. For your website or software, it is best to ask your web agency or IT supplier.

How do I know if my network equipment is updated?

Ask your IT partner for an overview of your router, firewall, switches and access points, with the software version and the date of the last update. During a Security Audit, we also check if default passwords were changed and who manages the equipment.

Know where you stand

The PHP flaw showed how fast things can go. If you know what you have and who does what, you can act fast. Start with the basics: your office. Request a Security Audit or sign up for the newsletter and stay up to date on the digital security of buildings.

Sources: NCSC via Rijksoverheid, Serious vulnerabilities in PHP; NOS, live blog 21 October 2026; php.net.