The PHP security flaws: what WordPress owners should check now

On Wednesday 21 October 2026, websites went dark around the world. Government departments, universities and businesses took their own sites offline on purpose. That wasn't an outage in the usual sense. They were waiting for an emergency fix to two critical flaws in PHP, the programming language that runs WordPress and a large share of the web.

The fix is out now. But it only protects your site once it's actually installed on your server, and updating WordPress doesn't install it. Here's what happened, and what WordPress owners and web managers should check.

The short version

• Two critical PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619, nicknamed "PHP2Shell") can let an attacker run code on your server without logging in.
• The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• Updating WordPress, your theme or your plugins does not update PHP. Your host (or whoever manages your server) has to do it.
• If you're on PHP 8.1 or older, you're on an unsupported version. Plan an upgrade now.
• Once you've patched, check that nobody got in before you did.

What happened

Details of two serious PHP flaws began leaking online on 20 October, before the planned coordinated disclosure. The PHP security team brought its release forward and published fixed versions on 21 October at around 14:00 UTC. Both flaws are rated 9.2 out of 10 (CVSS v4.0) for severity.

In plain terms, both bugs are in how PHP sets up and cleans up after each web request. A carefully crafted request can leave PHP's memory in a broken state, and an attacker can turn that into running their own code on the server. On sites running PHP inside Apache (known as mod_php), the PHP team says it has seen a working attack that runs before WordPress even loads. That means your WordPress security plugin never gets a chance to step in.

Ahead of the release, the UK's National Cyber Security Centre and CERT-EU advised organisations to consider temporarily taking sites offline if they couldn't protect them straight away. That's why so many sites went dark. Security firms have since reported attack attempts against unpatched servers, so this isn't a theoretical risk.

Is my WordPress site affected?

If your site runs on PHP, which every WordPress site does, assume you're affected until you've confirmed otherwise. According to the official PHP advisory, every PHP installation that serves web requests is in scope. That includes PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, so cheap shared hosting, managed WordPress hosting and your own VPS are all included.

What matters is the exact PHP version your server is running:

• PHP 8.2, 8.3, 8.4 or 8.5: you need at least 8.2.35, 8.3.36, 8.4.27 or 8.5.12 respectively. Anything lower is vulnerable.
• PHP 8.1, 8.0 or 7.4: these versions are end-of-life and get no official releases. The PHP team published minimal source fixes for people who build PHP themselves, and some hosts and Linux vendors ship their own backports. Don't assume you're covered. Ask, and plan an upgrade.
• Anything older: no fixes at all. This needs upgrading or taking offline.

One more date to note: PHP 8.2 reaches end of life on 31 December 2026. If you're patching 8.2 today, schedule the move to 8.3 or newer at the same time.

The checklist: what to check now

1. Find your PHP version. In your WordPress dashboard, go to Tools > Site Health, open the Info tab and expand Server. It shows the PHP version. Most hosting control panels (cPanel, Plesk) show it too.
2. Compare it with the fixed versions. 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or newer in the same branch.
3. Ask your host to confirm in writing. Many hosts apply patched packages from their Linux vendor, and the version number they show may not match the official one. A short email works: "Has the PHP running my site been patched for CVE-2026-109618 and CVE-2026-109619?" A good host will answer within hours.
4. Check every site, not just the main one. Staging sites, old campaign microsites, a forgotten blog on a subdomain: if it runs PHP and it's reachable from the internet, it counts. Forgotten sites are often the ones that get hit.
5. If you can switch PHP versions yourself (in cPanel's "Select PHP Version" or similar), pick a patched version and confirm it in Site Health afterwards. Moving up a major version, say 8.1 to 8.3? Test on staging first, because older plugins and themes can break.
6. Make sure the update has taken effect. If you manage your own server, update the packages and restart PHP-FPM or Apache. A process still running the old code isn't patched.
7. Take a fresh backup before you change anything, and keep it off the server.

If you can't patch today

The PHP team is clear that updating is the only complete fix. Workarounds reduce some attack paths but don't make a site safe. If your host can't patch quickly, you have three realistic options:

• Take the site offline temporarily, like many government sites did. If you do, show a maintenance page with an HTTP 503 (Service Unavailable) status. That's the code Google recommends, because it tells search engines the outage is temporary and protects your rankings. Serve the page from the web server or your CDN, not from PHP.
• Put a web application firewall in front of the site, such as Cloudflare. It may block known attack patterns, but it's not a substitute for patching. Make sure all traffic actually goes through it, because attackers who can reach your server's IP address directly can bypass it.
• Apply the official temporary hardening (for server admins). The PHP advisory lists settings that block the confirmed attack paths, including session.upload_progress.enabled=0, tighter post_max_size limits and, on PHP 8.5, fatal_error_backtraces=0. Each one has to be set at server or pool level, followed by a restart of every worker. Treat these as a stopgap only.

If your host can't tell you when it will patch, that tells you a lot about your host. It may be time to look at hosting that takes this seriously.

After the patch: check you weren't hit

Patching closes the hole, but it doesn't remove anyone who got in while it was open. Proof-of-concept code was circulating before and just after the release, so it's worth a quick look:

• Check WordPress users: look for admin accounts you don't recognise under Users.
• Look for unexpected PHP files, especially in wp-content/uploads, where there should be none. Also look for recently changed files in themes, plugins and the site root.
• Run a malware scan with your security plugin or your host's scanner, and check your host's logs for unusual requests or traffic spikes from 20 October onwards.
• Watch for warning signs: redirects to other sites, spam pages appearing in Google, outgoing spam email, or a "This site may be hacked" notice in Search Console.
• If anything looks wrong, change all passwords (WordPress, hosting, database, FTP/SFTP) and get the site cleaned properly. Restoring a backup without finding the entry point usually means getting hacked again.

What this means going forward

This one was unusual, because the flaw sat underneath WordPress, in a layer most site owners never think about. But the lesson is the same as with plugin vulnerabilities: the gap between a flaw being found and attackers using it is shrinking. Security researchers increasingly point to AI tools as one reason why. Sites that get patched within hours come through these events fine. Sites that sit unpatched for weeks are the ones that get hurt.

A few habits make the next one much less stressful:

• Know which PHP version every site runs, and keep it on a supported branch. See the official support dates.
• Agree with your host or developer, in advance, who applies emergency patches and who decides to take a site offline.
• Keep tested, off-site backups. They're your way back if something does go wrong.
• Get the WordPress security basics in place, so a server-level flaw is the only thing you need to worry about.

Need a hand checking your site?

If you're not sure which PHP version your site runs, or whether your host has patched it, I can check for you. I'll confirm the version, chase the host, test the upgrade on staging and look for signs of compromise. My WordPress maintenance plan clients already have this handled, and for everyone else there's one-off WordPress support.

Call me on 01403 910016 or get in touch and I'll give you a straight answer on where your site stands.