Your WordPress site runs on PHP. This week, that is the whole story.

On 21 October 2026 the PHP project shipped a security release for two flaws it rates critical, and said the thing a project rarely says in public: there are no complete mitigations, updating is the only safe choice (php.net, Oct 2026).

If you own a WordPress site, that release is about you, whether or not you have heard of it. WordPress is a PHP application. The flaws are in PHP itself, not in a plugin, so a site with every plugin up to date is still exposed until the server underneath it is updated. This guide says what happened, how to find out what you run, what to do this week, and when fixing stops being the right answer.

What happened on 21 October

The release fixes two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (php.net, Oct 2026). The day before, the project's advance notice rated both at 9.2 on CVSS 4.0 (php.net, Oct 2026). The research community calls the pair PHP2Shell.

In plain words, both let an attacker who has not logged in to anything run their own code on the web server. One is triggered when PHP runs out of memory while a request is only partly set up; the other lets state from one request survive into the next request handled by the same worker (php.net, Oct 2026). That is why there is no plugin-level fix: the problem is below everything your site does.

The US Cybersecurity and Infrastructure Security Agency issued an alert the same day. It says the flaws affect all PHP installations serving web requests, and that at the time of publication it had not observed exploitation (CISA, Oct 2026). Read that second part carefully. It means nobody had caught an attack yet, not that nobody will try.

Why "update your plugins" doesn't cover it

The fix went into the four PHP branches the project still supports: 8.2, 8.3, 8.4 and 8.5. PHP 8.1 and older no longer receive updates from the project. The security team published minimal source backports for 7.4, 8.0 and 8.1, which some Linux distributions and long-term-support vendors turn into packages, but your host has to apply them (php.net, Oct 2026).

CISA's alert singles out systems that continue to use PHP 8.1 or earlier, and tells organizations that cannot update to take PHP systems offline until they can (CISA, Oct 2026).

One more date matters. PHP 8.2 stops receiving security fixes on 31 December 2026 (php.net, Oct 2026). A site patched onto 8.2 this week is safe from this pair, and back in the same position at the next one.

Find out what you are running

You need two facts: the PHP version, and whether your host updates it for you.

• In WordPress: go to Tools, then Site Health, then the Info tab, then Server. The PHP version is listed there.
• In your hosting panel: cPanel, Plesk and most managed hosts show a PHP version selector or a "PHP settings" page. Some hosts let you change it there; some pin it.
• If you can't log in to either, ask whoever built or hosts the site for the PHP version and the exact release number. "PHP 8" is not an answer; "8.3.36" is.

Compare the number to the fixed releases: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or newer (php.net, Oct 2026). Lower than that on the same branch means unpatched. Any 8.1, 8.0 or 7.x means your host has to do more than click update.

What to do today, in order

This follows CISA's list, translated for a site owner (CISA, Oct 2026).

1. List every site you have. Not just the main one: the old campaign site, the staging copy, the one a former agency set up. PHP can be running where you have forgotten it is.
2. Patch the public ones first. Ask your host, in writing, whether the server is on a fixed release, and when it will be if not. Keep the answer.
3. If it can't be patched, take it down or put it behind something. CISA's own advice is to take a system offline until it can be patched. A web application firewall in front of the site is a stop-gap, not a fix.
4. Keep your plugins and WordPress itself current anyway. This flaw is in PHP, but the next one may not be, and an attacker who gets in through one hole stays through another.
5. Watch the server. CISA says to look for PHP worker processes that start shells or download tools. If you don't know how to look, ask your host whether they do.

If your host can't give you a supported PHP

Some sites can't simply be switched to PHP 8.2 or later: a theme or a plugin from years ago breaks on it, or the host pins old versions for everyone. Then you have a decision, not a ticket.

• Fix the site so it runs on a supported PHP. Usually a handful of plugin replacements and theme fixes. Worth it when the site is otherwise sound.
• Move to a host that keeps PHP current for you. Worth it when the site is sound but the host is the problem.
• Migrate off WordPress. Worth it when the site was due for a rebuild anyway, or when "a PHP application you don't control, on a version you can't name" is a risk you no longer want to carry.

The honest test: if the site has needed emergency work more than once this year, the third option is cheaper than it looks.

When a migration beats a repair

We have built and run 60+ client sites and stores since 2013, most of them WordPress. We still host and patch some of them, so this is not a post against WordPress. It is a post about who owns the risk.

A migration, the way we do it, keeps your content and your URLs and replaces what runs underneath: a content model in an open-source headless CMS, a Next.js front end, and the plumbing that a modern site should come with from day one, error reporting, analytics with consent, transactional email and a CDN in front. We built the order platform for a Florida lien-search firm that way, on Next.js and Strapi, and it is still running. Every old URL redirects to its new page, so search rankings carry over.

What a migration does not do: make the site maintenance-free. It moves the maintenance from "whatever version the host runs" to a build you own, with dependencies pinned and updated on a schedule you can see.

How to start

• Diagnosis, $199. Tell us what you run and what your host said. Within 48 hours you get a full backup, the PHP version and patch state in plain language, and a written quote for the fix, or for a move or a migration if that is the better answer. The fee is credited to whichever you choose.
• A care plan, $500–1,500 a month, if you want someone to own updates and patching after the fix, so the next release like this one is handled before you read about it.

Every number in this guide comes from the PHP project's own announcements and CISA's alert, linked where they appear. Prices are the ones we publish; nothing here is a quote until it is in writing for your site.