The WordPress PHP Version Problem: A Third Of Sites Get No Security Fixes.

Short answer: as of 5 September 2026, at least 32.8% of WordPress installs ran a PHP branch that receives no security fixes at all, counting only the three largest unsupported branches. Re-reading the full statistics later, and counting every branch with zero current support rather than only the largest three, put the real figure at 38.36%. PHP 8.2, a further roughly 24.8%, loses its security support on 31 December 2026. Checking a client’s wordpress php version takes one command, and the deadline is already on the calendar.

These numbers are not estimates. They come from the WordPress.org statistics API, which reports what installs actually report, and the support dates come from php.net’s own supported versions page.

Where every branch stands today

The amber row is the interesting one. It is the single most popular branch after 8.3, and its security support ends in under four months.*

Branch	Installs	Security support ends	Status today
7.4	17.2%	ended 2022	end of life
8.0	4.1%	ended 2023	end of life
8.1	11.5%	ended 2025	end of life
8.2	24.8%	31 Dec 2026	security only
8.3	25.1%	31 Dec 2027	supported
8.4	8.4%	31 Dec 2028	supported
8.5	2.9%	31 Dec 2029	supported

The distribution behind that:

PHP 7.4 alone, released in 2019 and unsupported since 2022, is still 17.2% of all WordPress installs.*

Add the red and the amber together and 57.6% of the WordPress web is either unsupported today or will be by New Year’s Day.

Re-reading the same API found a real undercount in the figure this post gave

I queried the same WordPress.org statistics endpoint again while expanding this post, and the three named branches in this post’s table held almost exactly steady: 7.4 at 16.99% (was 17.2%), 8.0 at 4.06% (was 4.1%), 8.1 at 11.38% (was 11.5%), summing to 32.43% against the original 32.8%. That part of the finding is confirmed, stable, and essentially unchanged months later.

Reading the full raw response rather than only the branches this post’s table names turned up something the original table did not capture:

curl -s https://api.wordpress.org/stats/php/1.0/

{"4.4":0.008,"5.1":0.003,"5.2":0.127,"5.3":0.265,"5.4":0.182,"5.5":0.154,"5.6":1.341,
 "7.0":0.592,"7.1":0.361,"7.2":1.414,"7.3":1.482,"7.4":16.987, ...}

Eleven more branches, PHP 4.4 through 7.3, every one of them years further past end of life than 7.4 itself, each carrying a small but real, non-zero share of live WordPress installs. Summed together they add another 5.93 percentage points that this post’s original “32.8%” headline never counted, because the table only named the three largest EOL branches rather than every branch reporting zero current security support.

The corrected total: 38.36% of WordPress installs run a PHP branch with no security fixes at all, not 32.8%. Add PHP 8.2’s 24.79%, security-only until the end of this year, and the combined at-risk-or-soon-to-be share is 63.15%, not the 57.6% this post states. Both corrections move in the same direction, understating the problem rather than overstating it, which is worth being direct about: the original figure was not wrong about the branches it named, it was incomplete about how many other branches exist below the ones anyone bothers to name individually. A site running PHP 5.6 is not a rounding error. It is a real, currently active WordPress install, and it belongs in this count as much as a 7.4 site does.

What end of life actually means for a client

It does not mean the site stops working. That is exactly the problem, and it is why this is a hard conversation to have.

A PHP 7.4 site runs fine. It serves pages, takes orders, and gives no outward sign that anything is wrong. What has changed is that when a vulnerability is found in the language itself, no fix will be written for that branch. Not delayed. Not deprioritised. Not written.

Your client is not running old software. They are running software that has left the support model entirely, on a schedule that php.net published years in advance.

The second effect is quieter and arrives sooner. Plugin and theme authors raise their minimum PHP requirement over time. A site on 7.4 gradually stops receiving updates for the things running on it, which means it accumulates plugins that will never be patched again, and the security exposure compounds from both directions.

Checking the WordPress PHP version, and upgrading in the order that saves time

three-week project. A plugin pulled from the directory will not be made compatible with PHP 8.4 by anybody.*

#	Check	Why
1	what the site runs now	wp eval 'echo PHP_VERSION;', not what the host’s dashboard claims
2	minimum PHP of every active plugin and theme	one abandoned plugin sets the ceiling for the whole site
3	anything already removed from the directory	an unmaintained plugin will never gain compatibility
4	deprecation notices on the current branch	today’s notices are the next branch’s fatal errors
5	run the target branch in staging, walk it	homepage, a form, checkout, admin, not static analysis alone

Start with the actual version, not the host’s control panel:

wp eval 'echo PHP_VERSION;'

CLI and web-server PHP are frequently different versions on the same host, and it is the web-server one that serves your visitors.

Then the ceiling, which is set by whichever plugin has the highest minimum:

wp plugin list --status=active --fields=name,version

One note on step four, because it is genuinely useful and rarely done. Turn on deprecation logging in staging on the current branch. Today’s deprecation notices are the next branch’s fatal errors, so you get a preview of the upgrade before you attempt it. Just do not leave that logging on afterwards, or you will publish the results to the internet.

What a stranger can already see

Before the upgrade conversation, it is worth knowing how much of this is public.

sites here do not, because a CDN or a hardened configuration strips it. Disclosure does not create the vulnerability, but it removes the guesswork for anyone scanning.*

Host	PHP version visible?
stock WordPress install	yes, exactly: X-Powered-By: PHP/8.3.33
woocommerce.com	no
wordpress.org	no
sitea.example	no
siteb.example	no
sitec.example	no

Caveat: six hosts, five of them ours or ones we track closely. Header disclosure being absent everywhere here says more about CDNs stripping the header by default than about any deliberate hardening. Check your own site’s headers rather than assume the pattern holds.

I re-checked the same five reference sites’ headers while expanding this post. Four are unchanged, still no PHP version disclosed. woocommerce.com now sends an X-Powered-By header where it previously sent none, but it names the hosting platform rather than a PHP version:

x-powered-by: WordPress VIP <https://wpvip.com>

That is a different category of disclosure entirely, worth distinguishing rather than folding into the same row as a version leak. Naming a managed hosting platform tells a visitor, or a scanner, which infrastructure provider is involved, useful reconnaissance in its own right, but it does not hand over an exact PHP version the way X-Powered-By: PHP/8.3.33 does. Reading a header change like this one carefully, rather than treating “a new header appeared” as automatically the same finding as before, is the same discipline this post already argues for when distinguishing version disclosure from the underlying support status: two things can look similar in a header dump and mean entirely different things once actually read.

Turn it off with expose_php = Off in php.ini, and treat that as tidying rather than as a fix. Hiding the number changes nothing about the branch underneath it, and a site that hides its version while running 7.4 has solved the smaller half of the problem.

How to raise it with a client

The version number means nothing to them. Two framings that work:

The support one. “The language your site is built on stopped receiving security fixes in 2022. If a flaw is found tomorrow, there is no update to install.”

The compatibility one. “Plugins are dropping support for this version. Every month the site stays here, fewer of the things it depends on can be updated.”

Avoid predicting a breach. You cannot know that, saying it is not honest, and it makes the rest of your advice easier to discount.

There is a third framing that works on clients who have been quoted for this before and said no. Put a date on it. “PHP 8.2 stops receiving security fixes on 31 December. If we move you in October it is a planned afternoon. If we move you in January it is an emergency, and emergencies cost more.” A published deadline is far easier to act on than a general sense that something is old, and this deadline is genuinely published, years in advance, by the people who maintain the language.

The honest counterpoint, which is worth saying out loud rather than waiting to be asked: an upgrade can break a site. That is a real risk and pretending otherwise damages your credibility. The answer is not to avoid the upgrade, it is to do it behind a restore point you have actually tested, in staging first, with the checkout and the forms walked afterwards. The risk of moving is a Tuesday afternoon. The risk of not moving accumulates every month and has no end date.

Why this is a portfolio problem

For one site, the check is one command. Across forty sites it is forty logins, and the answer changes whenever a host migrates a server or an upgrade is done for one client and not the others.

So it gets audited once, usually during onboarding, and then drifts. That is the same unbilled half hour that swallows every other check worth doing.

Protuno’s free audit reports the PHP version from a connected site, and the deadline above makes this a good quarter to have that list in one place. Straight with you as on every post here: Rook, the Security agent that would track branch deadlines across a portfolio, is built and named but not live yet.

If you do one thing after reading this: list the PHP version of every site you look after, in one document, with the branch deadline next to it. Four of those deadlines are already in the past, and one is 31 December.

Re-read the statistics API itself before quoting a percentage to a client, too, and count every branch it lists rather than only the largest few. This post’s own original figure needed exactly that correction, and a number that undercounts the problem is worth fixing the moment you notice, not defending because it was published first.