WordPress and the PHP vulnerability of 21 October 2026: check your version and protect your site

WordPress is written in PHP, and every page of your site goes through your host's PHP engine. The PHP vulnerability of 21 October 2026 (CVE-2026-109618 and CVE-2026-109619, see our full explanation) therefore affects every WordPress site, from the personal blog to the WooCommerce store, whatever the theme, the plugins or how up to date WordPress itself is. The good news: for most sites, the host applies the fix. The bad news: you have to confirm they did, and many sites still run a PHP version that will never get a fix.

Why updating WordPress is not enough

There is a common confusion between updating WordPress (the CMS, its themes and plugins) and updating PHP (the language that runs WordPress). The flaw of 21 October is in PHP. A perfectly up-to-date WordPress site, with every plugin on its latest release, remains vulnerable if the server runs PHP 8.4.26 or 8.1.x. And since the flaw can, on Apache with mod_php, be triggered before WordPress even loads, no security plugin can intercept it on its own.

Check your PHP version in two minutes

1. Log in to the WordPress admin.
2. Go to Tools, then Site Health, Info tab.
3. Open the Server section: the "PHP version" line shows the exact version.
4. Compare with the fixed versions: 8.5.12, 8.4.27, 8.3.36 or 8.2.35.

Two clarifications. First, if the version shown is 8.1.x, 8.0.x or 7.4.x, your site is on a branch with no fix: you need to change version, not wait. Second, on some Debian- or Ubuntu-based hosting, the fix may be applied without the version number changing. When in doubt, ask your host whether they have deployed the release of 21 October 2026.

Depending on your hosting

Managed WordPress hosting

Turnkey WordPress plans update PHP across all their servers. Check their status page or your inbox, and contact support if you have no information by the end of the day. Also check that your site has not stayed on an old branch by choice (some panels let the customer pick the version).

Shared hosting (cPanel, Plesk or a custom panel)

The host rolls out the fix to every account on the server. On your side, open the panel's PHP version manager ("Select PHP Version", "MultiPHP Manager" or equivalent) and make sure your domain uses a supported branch. If the panel still offers 7.4 or 8.1 by default, move to 8.3 or 8.4 after the test described below.

VPS or dedicated server

Nobody will update PHP for you. The administrator has to install the fixed packages and restart PHP-FPM or Apache so that every process uses the fixed version. The detailed procedure per system is in how to update PHP on your server. This is the group of sites that must act today.

Switching PHP branches without breaking the site

Going from 8.1 to 8.4 is more than a security update: some functions were deprecated or removed, and an old theme or an abandoned plugin can throw a fatal error. On a store, a broken checkout costs money from the first hour. The method that avoids bad surprises:

1. Full backup before any change (files and database).
2. Plugin and theme inventory: note those not updated in more than a year. They are the likely troublemakers.
3. Test on a staging copy: most hosts offer one in one click. Switch the copy to the new PHP version and walk through the whole site.
4. Check the key journeys: main pages, forms, search, customer account, cart and checkout, email sending.
5. Switch production, ideally at a quiet time, then check again.
6. Watch the error logs for 48 hours.

If the host forces the update without notice, at least take the backup and run the checks afterwards. And if a plugin blocks the version upgrade, look for a maintained alternative rather than staying on a vulnerable PHP branch. Our guide update WordPress safely describes the same cycle for the CMS.

Extra layers of protection

• Cloudflare or another WAF: on Cloudflare's free plan the managed firewall rules are on by default; on paid plans, check that the rules are set to "block" and not just "log". An attacker can sometimes bypass the proxy by targeting the server's address directly: it is a layer, not a fix.
• Disabling `session.upload_progress` on the server side (WordPress does not use this feature) closes one of the confirmed attack paths for CVE-2026-109619. On shared hosting, ask the host rather than editing the configuration yourself.
• A security plugin does not fix a flaw in the PHP engine. It remains useful for detecting files modified afterwards.

What to watch over the next few days

Even with a fixed site, keep an eye out for signs of a compromise that happened before the update: unknown PHP files in wp-content/uploads, administrator users you did not create, redirects to foreign sites, unexplained load spikes, spam emails sent from your domain. If you spot any of these, follow our emergency guide for a hacked WordPress site.

Have your WordPress looked after by a team

Checking a PHP version takes two minutes. Doing it for every alert, on every site, with a staging test and a backup each time, is regular work. It is the core of our managed services: we know the PHP version of every site we look after, and an alert like the one of 21 October triggers a check of every site within the day. Let's talk about your site if you would like it to be one of them.