The October 21 PHP Vulnerability in Plain Language: What Happened and What to Do Now

What is PHP?

PHP is a programming language that runs on the server, not in your browser. Think of a website as a restaurant. What you see on your screen is the plate that’s served at the table. PHP is the kitchen. Every time someone opens a page, the kitchen prepares that page: the text from the database, the menu, the contact form.

WordPress runs on PHP. So do many online stores, customer portals, and intranets. If you have a WordPress site, you’re using PHP—even if you’ve never seen that word before.

What Went Wrong

On October 20, the PHP team announced that a security update for two critical vulnerabilities would be released the following day. CERT-EU, the cyber security service of the European institutions, warned that these vulnerabilities could lead to remote server takeover. To use a restaurant analogy: someone from outside could walk into the kitchen and do whatever they want there, without logging in.

According to the NCSC, all it took was a single simple request to the server. The consequences could be severe: a server being taken over, data leaks, or a website that no one can log into anymore.

The tricky part was the timing. The announcement came a day before the update. So everyone knew something serious was going on, but couldn’t fix it yet. According to the NCSC, code demonstrating how the vulnerability works had already been made public on October 21, but the NCSC had not yet observed any active exploitation.

On October 21, PHP released the updated versions: 8.5.12, 8.4.27, 8.3.36, and 8.2.35. There was no regular update for PHP 8.1 and earlier versions. For versions 7.4, 8.0, and 8.1, the PHP team provided only a minor fix for those who compile PHP themselves. For most websites, this means switching to a newer version.

Not just websites

The NCSC pointed out something that received little attention in the news. PHP isn’t just found in websites. It’s also found in network equipment, in the dashboards of smart devices, and in virtually all types of management screens that you open via a browser to change a device’s settings. Think of the management page of a router, a storage device, or a camera system.

With devices like these, you don’t update PHP yourself. You have to rely on the vendor to release a new version of the software. If an admin interface like that is exposed on the internet, that’s the first thing you should shut down.

Why Websites Went Offline

CERT-EU issued clear guidance: if you cannot apply the update immediately, take your internet-facing applications offline until the update is available. The NCSC recommended evaluating each system that uses PHP and is connected to the internet on a case-by-case basis, including whether to shut it down.

Many organizations opted for caution. The NCSC took ncsc.nl offline. Local media reported that municipalities in the Zaanstreek region, among others, took their websites offline as a precaution. A website being offline for a few hours is annoying. A server being compromised is much worse.

Why a plugin update Wasn’t Enough

Many people are familiar with the red dot in WordPress: it means there are updates for your theme or plugins. Those updates are important, but they don’t fix this vulnerability. The vulnerability wasn’t in WordPress, but in PHP itself—the kitchen beneath the restaurant. It’s the hosting provider that updates that kitchen, not the website.

That’s why the question on October 21 wasn’t about plugins, but about the server: who manages it, and how soon after the update was it updated?

What We Did That Day

For clients whose websites we manage, we work with trusted website partners who monitor the servers. Our website partner reports that the team was ready early in the day and implemented additional security measures on the servers before the update. The firewall for all servers received an update to block attacks exploiting the vulnerability, and several entry points that an attacker could have used were temporarily disabled. This allowed websites to remain online throughout the day. After the release, the partner immediately rolled out the update to all servers. During that rollout, a small number of websites were temporarily taken offline as an extra security measure. We provided updates on the status of their websites to customers who asked us how their sites were faring. Even before the update We warned on LinkedIn that a plugin update wasn’t enough.

We followed the same checklist for our own websites. We created a fresh backup and stored it off the server. We identified which sections actually require PHP, and disabled PHP for sections that only display a static file. If something isn’t running, it doesn’t need to be updated. We checked the version ourselves after the update, rather than relying on a notification. Our own websites are now running on the patched version.

Five Questions for Your Website Administrator

You don’t have to be a programmer to set this up properly. You do, however, need to know the answers to these five questions:

1. What version of PHP is my website running on? In WordPress, you can find this under Tools, Site Health, the Info tab, under the Server section.

2. Who updates the server, and how quickly? For most websites, it’s the hosting provider. If you don’t know who that is, that’s the first thing you should find out.

3. Am I running a version that still receives updates? There was no regular update for PHP 8.1 and earlier. If you’re using one of those versions, you’ll need to upgrade—don’t wait.

4. Is my backup stored off the server? A backup stored on the same server as the website will be lost if that server is taken over or goes down.

5. What websites and sections do I actually have? An old promotional page, a forgotten test site, a customer portal. If you don’t know about them, no one will update them.

What the Security Check Does and Does Not Detect

First, the boundary. The Security Check looks at your site from the outside, just as a visitor would. It can only tell if the server behind your website has been updated if that server explicitly states its PHP version. On a properly configured server, that version is hidden. The Security Check will then indicate that it’s not visible from the outside. In that case, you’ll find out whether you’re up to date from your hosting provider or by checking Site Health yourself.

New: a separate section for this vulnerability

Since October 22, the Security Check has included a section called “Reported PHP Version” under “Security.” If your server reports a PHP version, the Security Check compares it to the corrected versions from October 21. Here’s what you’ll see:

• A vulnerable version. If your version is older than the patched version in the same series, the Security Check will indicate this, along with the minimum version you need. This is factored into your score.
• PHP 8.1 or older. Those versions no longer receive regular updates. He also mentions this, advising users to switch to a version that still receives updates.
• A corrected version. He then says that the fixes from October 21 are included. That doesn’t earn any extra points: a visible version should never score higher than a hidden version. The recommendation to hide the version remains in effect.
• A version with an appendix. Linux distributions such as Ubuntu and Debian release fixes without increasing the version number. If there is such a suffix after the version number—or if it is a test version—it is not immediately apparent from the outside whether the fix is included. That is precisely what the Security Check indicates, rather than leaving it to guesswork.
• It does detect PHP, but not the version. If your site sets a PHP session cookie or if the server simply mentions the word “PHP,” it will report that your site appears to be using PHP. It does not, however, provide any information about the version.

It doesn’t send any additional requests to your server to do this. It simply reads what your server already sends back during a normal visit to the homepage. No login attempts, no search for hidden pages. We update the list of patched versions as soon as PHP releases a new security update.

The rest of the exterior

In addition, the Security Check measures what you would normally check on a day like October 21: your certificates, your security headers, and your email and DNS settings. You’ll find an expired certificate or a missing security header just as easily as if you were checking your websites one by one. And it checks whether your server reveals to everyone which software and version it’s running. An attacker can then immediately see which known vulnerabilities are worth exploiting.

You don’t need an account to do this. Run the Security Check for your own domain. If you receive a notification about your PHP version, or if it says that it can’t be seen from the outside, ask the person who manages your website questions 1 and 2 above.

A Website That’s Maintained

Most websites are built and then forgotten—until a day like October 21. We handle website development and management in collaboration with our website partners: the server is kept up to date, backups are stored off-site, and in the event of a security breach, you’ll hear from us about what’s going on before you read about it in the newspaper.

Would you like to know how your website is doing, or would you like a website managed this way? Schedule a consultation. We operate in compliance with ISO 27001:2023, ISO 9001:2015, and NEN 7510:2024.

Frequently Asked Questions

My website stayed online. Does that mean it’s secure?

Not automatically. Staying online was a choice, not a requirement. Your website will only be updated if the server is running version 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or a newer version in the same series.

Can the Security Check tell if my website has been updated?

Only if your server specifies its PHP version itself. In that case, it compares it to the updated versions from October 21. If the version is hidden, it says that it cannot be seen from the outside. A hidden version is fine, but it’s not proof that you’re up to date.

Do I need to do anything myself?

Ask whoever manages your website which version it’s currently running. For a WordPress site, you can also check this yourself in Site Health.

Has the vulnerability already been exploited?

On October 21, the NCSC reported that sample code had been made public, but that it had not yet observed any active exploitation. That could change. That is why updating is the only real solution.

Does a security plugin help in WordPress?

It wasn’t this vulnerability. It was in PHP itself. A plugin runs on top of PHP and can’t fix the underlying issues.

Does this also apply to my router or storage device?

That’s possible. According to the NCSC, PHP is also found in network equipment and in management interfaces that you access through a browser. Check to see if the vendor has released an update, and make sure the management interface isn’t accessible on the internet.

My website runs on PHP 8.1 or older. What should I do now?

Have it migrated to a version that still receives updates. First, make a backup, and then test to see if your theme and plugins continue to work properly.

Conclusion

The PHP vulnerability showed that a website isn’t ready just because it’s live. Someone has to maintain the server, and you need to know who that is. The organizations that remained calm on October 21 already knew the answer to that question before the update.

Don’t know the answer, or would you like someone to keep track of it for you? Schedule a meeting with ALTA-ICT.

Sources

PHP, News Archive 2026: announcement from October 20 and security advisory from October 21.
CERT-EU, Security Advisory 2026-018.
NCSC via Rijksoverheid, Serious Vulnerabilities in PHP (October 21, 2026).
NCSC, Security Advisories: website post “Serious vulnerabilities in PHP: prepare to patch” (October 21, 2026).
Accessed October 22, 2026.