Two critical PHP vulnerabilities: update now, and remember the server

On 21 October 2026 PHP released security updates for two critical vulnerabilities. Both can let an attacker run code on the server without being logged in. Both are rated 9.2 out of 10.

At the same time, Kombit — the Danish municipalities' shared IT organisation — has taken several public systems fully or partly offline, among them Aula, the platform Danish schools use to reach parents. Their press chief points at the layer underneath: "It is PHP, which sits under Aula." Kombit also stresses that it does not know whether anything was breached; the shutdown is a precaution.

What happened?

The PHP project gave notice a day ahead and shipped the fixes on 21 October at 14:00 UTC. Two vulnerabilities are closed:

Both are classed as unauthenticated remote code execution. That is the worst category there is: the attacker needs no username, no password and no link for anyone to click.

How do you find out which PHP version you run?

It takes under a minute, and you do not need to be a developer. Pick whichever route you have access to:

• In WordPress: Tools → Site Health → Info → Server. The line is called "PHP version".
• In your host's control panel: most hosts have a page named something with "PHP" or "PHP version", where it is both shown and changed.
• With server access: run the command directly.

# On a server you have SSH access to
php -v

# Note: the CLI version can differ from the one the website runs.
# What matters is the one the web server uses (PHP-FPM, mod_php, LiteSpeed).

If it shows 8.5.12, 8.4.27, 8.3.36 or 8.2.35 — or anything newer — you are covered for these two vulnerabilities. A lower number on the same branch means the update is missing.

Which PHP versions fix the vulnerabilities?

Note the bottom row. PHP 8.2 stops receiving security fixes on 31 December 2026 — just over two months away. Update to 8.2.35 now, but use the occasion to plan the move to 8.3 or 8.4. Otherwise the next notice like this one will find you with no fix to install.

On PHP 8.1 or older you no longer get ordinary updates from the PHP project. In this case, though, the security team has published fixes for 7.4, 8.0 and 8.1 that can be built from source, and many hosts backport themselves. Ask your host — and make a plan to get onto a supported version while you are at it.

How to update PHP, step by step

1. Find out which PHP version you run — see the section above.
2. Take a fresh backup of files and database before touching anything. A backup you have never tested is a hope, not a plan.
3. Update PHP. On ordinary shared hosting that is usually a setting in the control panel. On your own server it is the package manager.
4. Check afterwards that the version actually changed and the site still works. Look at the front page, a subpage, the contact form — and if you run a shop, put a test order all the way through.
5. If you hear nothing from your host, ask them directly. Silence is not the same as it being handled.

Why this reaches further than people think

"PHP is dead" is a claim that has held up remarkably badly. The reality is that the language sits underneath a very large share of the Danish internet — from the local club's website to the municipality's parent portal.

It is also why a vulnerability like this is different from a hole in a plugin. A plugin you can switch off. PHP is the ground the rest stands on. Update WordPress, your plugins and your theme, and you have updated the house — not the ground under it.

This is rarely a question of neglect. It is a question of nobody having decided who owns the layer beneath the system. If you are unsure who updates PHP on your solutions, the answer is most likely: nobody.

And it is rarely the break-in itself that costs the most — it is the months afterwards. I have cleaned up after months of hidden malware on a Danish WordPress site, where neither the theme nor a plugin was the way in. The fewer layers that have slipped out of sight, the shorter that work gets — and the fewer dependencies an installation carries, the less there is to lose track of.

Frequently asked questions about the PHP update

Is my WordPress site affected?

If it runs a PHP version below 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then yes — whatever theme and plugins you use. The vulnerabilities are in PHP itself, not in WordPress. Updating WordPress, the theme or your plugins does not help.

My site is on shared hosting. Does the host not do this themselves?

Most shared hosts do update PHP themselves, often within days. But you usually choose which PHP version your site runs on — and if you are on a branch they no longer support, it will not be updated for you. Check your version, and ask them directly if you are unsure. Silence is not confirmation.

Can it wait until next week?

I would not let it. Both vulnerabilities can be exploited without logging in, and the PHP project states there is no complete mitigation. Once a fix is public you can reason backwards from it, and exploitation attempts usually follow quickly.

Does a firewall or a security plugin help?

Not reliably. A WAF or a security plugin can block known attack patterns, but it is still PHP that executes the request. The PHP project says outright that there is no complete mitigation. Updating is the only real fix.

What if the update breaks my site?

Within the same branch — say 8.3.35 to 8.3.36 — that essentially never happens. It is jumps between major versions, 8.1 to 8.4 for instance, that can require adjusting old code or outdated plugins. Take a backup first and test the site afterwards. If something falls over, you can switch back and have it fixed before trying again.

How do I avoid ending up here again?

By someone owning the layer beneath the system. That is exactly what a service agreement covers: monitoring, backup and updates — PHP included — so they happen before they become news. And by keeping the number of dependencies down, so there is less to keep track of.

If you cannot get to it yourself

If you are unsure whether your sites are affected, or you have several to keep track of, say so. I can check the PHP version, take a backup, update and test afterwards.

It is also exactly what a service agreement covers: someone keeping watch, and updates happening before they turn into news. Write to hej@mickeyr.dk, or get in touch here.

Sources

• PHP: security advisory and releases, 21 October 2026
• PHP: supported versions and security-fix end dates
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• TV 2: IT threats against public systems (live blog, in Danish)