If you look after websites for clients, this was a long week. On 20 and 21 October, two critical bugs in PHP were made public. PHP is the language under WordPress, Drupal, Joomla and most of the web's content management systems, and these bugs, named PHP2Shell, let an attacker run their own code on a website's server without logging in. Within days, government websites in Finland, the Netherlands and France had been taken offline as a precaution, and the NSA was telling organisations that couldn't update to take their systems offline until they could.
This post covers what happened, what to do today if you have clients on WordPress, and why the websites Klaudius builds had nothing to patch.
What happened
- The bugs are in PHP itself, not in WordPress. CVE-2026-109618 and CVE-2026-109619 sit in the PHP interpreter, underneath whatever runs on top of it. Wiz Research, who found them, showed they could run code on servers running the latest WordPress, Drupal and Joomla without logging in. A perfectly maintained WordPress site, every plugin up to date, is still exposed if the PHP under it isn't patched.
- Almost every version is affected. Every PHP version from 5.4, released in 2012, through 8.5 is affected by at least one of the two bugs. Wiz estimates PHP runs around 70% of the world's websites. That doesn't mean 70% are vulnerable, but plenty are: 35.1% of WordPress sites run a version of PHP that no longer gets official fixes.
- Attacks started fast. watchTowr has seen attacks on its honeypots since 21 October, the day the fixes shipped, and working exploit code is public.
Credit where it's due: PHP's maintainers are a small team, and they shipped fixed releases for four versions of PHP at once.
If you look after WordPress sites: what to do today
- Find out which PHP each site runs. In WordPress, go to Tools → Site Health → Info → Server, where the PHP version is listed. Or ask the host.
- Check it against the fixed releases: 8.2.35, 8.3.36, 8.4.27 or 8.5.12. If the host uses a Linux distribution's own PHP package, the version number may not change after the fix, so check the host's or the distribution's security notice rather than the number.
- Don't rely on WordPress updates. Updating WordPress, a theme or a plugin doesn't fix this. The fix comes from whoever runs PHP, which on most hosting is the host, so ask them in writing whether they've patched. Automattic says WordPress.com, WordPress VIP and Pressable are already protected.
- Plan the move off old versions. PHP 7.4, 8.0 and 8.1 get no official fix: only a patched package from a Linux distribution or a long-term-support vendor, or an upgrade to 8.2 or later. Anything older than 7.4 gets nothing at all. Old plugins can break on a newer PHP, so try the upgrade on a copy of the site first.
- If a site can't be patched today, restrict it. The advice from the NSA and Europe's CERT-EU is to take it offline or cut off public access until it can be fixed. A firewall service in front of the site can block known attacks while you wait, but PHP's own position is that no configuration change fully mitigates the bugs: only the update does.
- Look for signs it has already happened. Wiz lists bursts of server errors, memory-limit errors after unusual uploads, and oversized session cookies, and the UK's NCSC has warned about backdoors left behind. Wiz also reports that one of the bugs can leak the server's memory, which can hold passwords and keys, so for any site that sat unpatched after 20 October it's worth changing its database password, API keys and WordPress security keys.
Then tell your clients what you did. Most of them saw the headlines, and "already handled" is what they want to hear from whoever looks after their website.
Why Klaudius sites had nothing to patch
No website Klaudius builds runs PHP, so there was nothing to do this week. Two things worth knowing when a client asks:
- There's no plugin layer. WordPress core is rarely the problem. Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025: 91% were in plugins, 9% in themes, and WordPress core had six, all low priority. Plugins are where the patching goes week in, week out. A Klaudius site has none: its bespoke content management system, booking system and live Google rating are built into the site's own code.
- The content management system doesn't run on PHP either. Each client's is built around their own website, runs without PHP or plugins, and keeps the owner's text and photos in the hosting platform's own storage rather than in a database server.
The reason most clients stay on WordPress
Ask an agency why a client is still on WordPress and the answer is rarely its security record. It's this: "I need to be able to change it myself."
Klaudius answers that with a bespoke content management system for each client: built around their own website, and added in a few clicks to any site Klaudius builds and hosts on Vercel. The owner signs in at their own site's /admin, clicks the text on their pages to change it, and swaps a photo straight from their phone. Nothing goes live until they press Publish, any change can be undone, and their last 20 published versions are kept. Everyone who helps with the site gets their own login and role, and repeated sign-in attempts are cut off at the hosting platform's edge.
The owner gets the part of WordPress they actually wanted, editing their own website, without the parts that made this week what it was: no PHP to patch and no plugins to keep updated.
What to say when a client asks
Every business owner with a website has now heard that websites were at risk this week, so expect the question. An honest answer for a Klaudius site: "It doesn't run WordPress, PHP or plugins, which is where this week's problem was. And I look after the updates."
One thing not to do is use the headlines to frighten prospects. A cold message saying "your website is vulnerable" reads like a scam, tends to land in spam, and is usually something you can't verify from the outside. Pitch what the business gets, a better website they can edit themselves, and let the news do its own work.