PHP 8.1 end of life: why it’s now urgent for WordPress

Why PHP 8.1’s end of life suddenly matters

“End of life” has always sounded like a problem for later. Your WordPress site runs fine on PHP 8.1, nothing is obviously broken, and the next thing on the list is always more urgent. For years that was a defensible gamble. In October 2026 it stopped being one.

When a PHP branch reaches end of life, the PHP project stops shipping releases for it — no bug fixes, and crucially no security fixes. The branch isn’t deleted from the internet; it just stops getting maintained. As long as no serious hole turns up, you don’t notice. The moment a serious hole turns up, you’re on your own.

That moment arrived. PHP2Shell — the pair of critical flaws CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2 — is an unauthenticated remote-code-execution bug in the PHP runtime itself. On 21 October 2026 the PHP project released fixes for every supported branch: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For the end-of-life branches — 7.4, 8.0 and 8.1 — there was no official binary release. The project published source-only backports on dedicated branches and left it to Linux distributions and hosting vendors to build packages from them. Anything older than 7.4 got nothing at all.

EOL branches

8.1 · 8.0 · 7.4 (and older)

PHP2Shell fix for them

Source-only backport — no official binary

Supported & fixed

8.5.12 · 8.4.27 · 8.3.36 · 8.2.35

WordPress recommends

PHP 8.3 or newer

PHP 8.2 security fixes end

31 Dec 2026

The practical upshot: if your site was on an EOL branch, getting patched meant hoping your specific host or distro had built one of those backports — and most owners had no quick way to tell. Had you been on a supported branch, you’d have taken an ordinary update the same day. That is the whole argument for staying current, delivered in a single afternoon.

PHP support windows, branch by branch

Each PHP branch gets roughly two years of active (bug-fix) support, then two more of security-fix-only support, then nothing. The dates below come from php.net’s supported-versions page. Pick your branch to see exactly where it stands and what it means for PHP2Shell.

Here’s the same information as a timeline, so you can see the cliff edges coming:

1. By end of 2026

   PHP 8.2 leaves support

   After 31 December 2026, PHP 8.2 gets no more security fixes and joins the EOL list. If you’re on it, plan the move to 8.3 or 8.4 during 2026.

2. Now

   PHP 8.3 and 8.4 are the safe choices

   WordPress.org recommends 8.3 or greater. PHP 8.4 is supported with security fixes to the end of 2028 and is a comfortable target for most sites.

3. Already past

   PHP 8.1, 8.0 and 7.4 are end of life

   No official upstream fixes. These are the branches PHP2Shell left without an official binary release. Treat anything on this line as needing an upgrade.

What actually happens if you stay on EOL PHP

The risk of an unsupported runtime isn’t abstract. It plays out in a predictable sequence, and PHP2Shell walked through every step of it in a single week.

• A flaw is found and disclosed. It affects every branch, old and new, because the buggy code has been there for years — PHP2Shell is believed to reach back to PHP 5.4 (2012).
• Supported branches get a fix immediately. Sites on 8.2, 8.3, 8.4 and 8.5 took an ordinary update on day one.
• EOL branches get a fix maybe, eventually, from someone else. For PHP2Shell, 7.4/8.0/8.1 got source-only backports; whether you could install a fix came down to whether your particular distro or host built a package — and when.
• Attackers scan for the stragglers. Cloudflare reported attempts against PHP2Shell climbing from thousands to millions after disclosure; exposure scans found over a million internet-facing PHP hosts still on EOL versions. Unpatched servers are exactly what mass scanning is for.

There’s a second cost that has nothing to do with any single CVE. Plugin and theme authors eventually drop support for old PHP, so staying on 7.4 or 8.1 slowly cuts you off from updates you do want — including the security updates that fix the WordPress-layer problems. The longer you wait, the bigger the jump becomes and the more likely something breaks when you finally make it. An old PHP version is a debt that compounds.

Government guidance drew the same conclusion. For organisations that can’t patch immediately, or that are still running PHP 8.1 or older, CISA’s advice during PHP2Shell was to take the affected systems offline until they could be updated or upgraded. That is how seriously regulators now treat an unsupported runtime facing a live, critical flaw. If you want the full picture of PHP2Shell and how it reaches WordPress, start with our PHP2Shell and WordPress guide, and see our WordPress security guide for the wider hardening checklist.

So, are you affected?

Answer three questions and this checker — which runs entirely in your browser and sends nothing anywhere — will tell you where an EOL version leaves you against PHP2Shell:

How to check which PHP version you’re on

The number that matters is the PHP that serves web requests for your site, not whatever a command line happens to report. The quickest reliable source is inside WordPress itself:

• wp-admin › Tools › Site Health › Info › Server. Read the PHP version row — that’s the exact patch level answering your visitors — and note PHP SAPI too (fpm-fcgi, apache2handler or litespeed).
• cPanel. Open MultiPHP Manager or Select PHP Version; the version column shows the branch per domain, such as ea-php81 for PHP 8.1.
• Managed host dashboard. Usually under the site’s Tools or Settings page as “PHP version” or “PHP engine”.

A very old version also announces itself: WordPress shows a “PHP Update Required” box on the Dashboard, and the Site Health Status tab flags an outdated runtime. For the full set of methods, including the command-line checks for your own server, see how to check and update your PHP version in WordPress.

How to upgrade from PHP 8.1 to 8.3 or 8.4

The switch itself is a dropdown in your hosting panel. The work is making sure nothing on your site depends on code the newer PHP removed. A safe order:

• Pick a target. Go to PHP 8.4 if your plugins declare support for it, or 8.3 if you want the version WordPress.org has recommended longest. Both are supported for years yet; don’t stop at 8.2, which leaves support at the end of 2026.
• Back up files and database and keep a copy off the server.
• Update WordPress core, plugins and themes so you’re testing the newest code against the new PHP. Replace any plugin with no update in the last couple of years — those are the usual cause of fatal errors on new PHP.
• Test on a staging copy. Switch staging to the new version, then click through the homepage, a post, forms, login and any checkout or membership flow.
• Switch the live site in the same panel, re-test, and watch wp-content/debug.log for new Fatal error lines. Deprecated notices are warnings, not breakage.
• Keep the old version one click away so you can roll back in a minute if something important breaks — then fix it on staging and try again within days, not months.

The mechanics differ a little by host. We have step-by-step walkthroughs for the two most common setups: updating your PHP version in cPanel and updating PHP on an Ubuntu or Debian server. On a managed host you may not control PHP at all — in which case your job is to confirm they’ve patched and upgraded it for you; our what to ask your host guide has a copy-paste email.

The option with no PHP version to track

PHP upgrades never stop. A new branch lands every year, each one supported for about four, and every few years a flaw like PHP2Shell turns the calendar into an emergency. For most site owners the sensible answer is to put that job on a managed host that patches and upgrades PHP for them — and to actually check they do.

There’s a more structural answer, too. Most WordPress sites are content sites: pages change a few times a week and are read thousands of times a day. Running PHP on every one of those requests means every PHP branch, every end-of-life date and every PHP flaw is your problem. Take PHP out of the request path and all of that goes with it.

That’s what Presscomet is: the same wp-admin, block editor, permalinks and REST API you already know, rebuilt to run on Node.js with a single SQLite file and no PHP runtime. There’s no PHP version to track, no end-of-life date to watch, and the entire PHP class of vulnerabilities — PHP2Shell included — simply doesn’t apply, because PHP isn’t there.

If an endless PHP-upgrade treadmill is the part of WordPress you’re tired of, check your site against Presscomet — the migration only reads your public site and lists what would move over, so trying it changes nothing on your server. Or read Can you run WordPress without PHP? for the longer version of the idea.