PHP Versions and Hosting Risk: Why Old PHP Is Not Just Slow

"Upgrade your PHP, it's faster" is the version of this advice most site owners have heard, and it is the least important part. The real cost of an old PHP branch is that nobody is fixing its security bugs any more — and most WordPress sites on the internet are in exactly that position today. The fix is usually a dropdown in your hosting panel and half an hour of testing.

PHP support dates in this article were taken from php.net/supported-versions and the WordPress install statistics from the wordpress.org stats API, both checked on 28 July 2026.

How the PHP support lifecycle works

Every PHP release branch gets a fixed four-year window: two years of active support, when ordinary bugs and security issues are fixed in regular point releases, then two years of security-only support, when critical security issues are fixed and nothing else. After that the branch is end of life and gets no upstream patches at all.

Here is where each branch stands today:

Two dates deserve a calendar entry. PHP 8.2 goes end of life on 31 December 2026 — five months from now — and PHP 8.4 leaves active support the same day. If you are on 8.2 you have a deadline; if you are on 8.3 you are already past the point where ordinary bugs get fixed.

What "end of life" actually costs you

Three things, in descending order of how much they should worry you.

Unpatched vulnerabilities. When a security issue is found in the PHP engine or a bundled extension, the fix lands in supported branches. An end-of-life branch gets nothing: the vulnerability is public — that is the point of coordinated disclosure — but your fix is not. One honest caveat: if your host runs PHP from a Linux distribution package (Debian, Ubuntu LTS, RHEL), the distribution may backport security fixes past upstream end of life. That is real protection, but it covers only what the distribution chooses to patch, so confirm it rather than assume it.

Compliance exposure. If you take card payments, PCI DSS 4.0 requirement 12.3.4 has been in force since 31 March 2025. It obliges you to review every technology you use at least annually, confirm the vendor still issues security fixes, and produce a management-approved remediation plan for anything that does not. "We run PHP 7.4" is a finding, not a footnote.

Compounding upgrade debt. Every year you stay put, the jump gets larger and more of your plugins and libraries fall out of their own support windows. Moving from 8.3 to 8.4 is usually uneventful; moving from 7.4 to 8.4 crosses a major version boundary and several rounds of deprecations at once.

The real-world numbers are worse than you would guess

The wordpress.org statistics API publishes the PHP version distribution across WordPress installs. Checked on 28 July 2026:

Grouped by support status:

• About 40 % run a PHP version that is end of life — 8.1 or older, receiving no upstream fixes.
• About 49 % run a version in security-only support — 8.2 and 8.3.
• About 10 % run a version in active support — 8.4 and 8.5.

PHP 7.4 alone, end of life since 28 November 2022, still accounts for nearly one site in five — the largest single version share after 8.2 and 8.3.

Performance is the smaller half of the argument

It is a genuine benefit — the jump from PHP 7.x to 8.x brought the JIT compiler and a long run of engine optimisations, and each release since has trimmed more. On a real WordPress site it shows up as lower time to first byte and more requests served before your PHP workers saturate: the difference between a shared plan absorbing a traffic spike and queuing requests until they time out.

But treat it as a bonus. If you upgrade PHP hoping to fix a slow site, you will usually find the real culprit was caching or a bloated wp_options table instead.

WordPress, plugins and the compatibility excuse

The official WordPress requirements recommend PHP 8.3 or greater, alongside MariaDB 10.11+ or MySQL 8.0+. WordPress will still run on PHP 7.4, and the page says so — while explicitly warning that those versions have reached end of life and may expose the site to security vulnerabilities.

The usual objection is "a plugin needs the old version". Sometimes true, more often untested. Two reframings:

• A plugin that cannot run on a supported PHP release is itself unmaintained — a bigger risk than the PHP version, because plugins run with full access to your database.
• Compatibility is testable in an afternoon on a staging copy. Guessing about it for two years is not a strategy.

If you are auditing the wider stack, our WordPress hosting checklist covers the rest of the environment the PHP version sits in.

Upgrading without breaking production

1. Find out what you are running. WordPress shows it under Tools → Site Health → Info; otherwise use your host's control panel.
2. Clone to staging. If your plan has no staging, that is itself worth noticing.
3. Update everything else first — core, plugins, themes, Composer dependencies. Most upgrade failures are stale third-party code, not PHP.
4. Switch staging one branch at a time: 8.1 → 8.2 → 8.3 → 8.4, not a single leap. Each step tells you which change broke what.
5. Turn error logging on and exercise the site properly — front page, checkout, forms, admin, cron jobs. Deprecation notices are warnings, not failures, but read them.
6. Check your extensions. imagick, intl, redis, soap and payment SDKs are the usual gaps.
7. Switch production in a quiet window, keep the previous version selectable, and watch the error log for 24 hours.
8. Write down the next deadline. Landing on 8.4 today means 31 December 2026.

What to ask a hosting provider

• Which PHP versions can I select, per site? A modern host offers at least the current two branches, set independently per domain.
• What is the default for a new install? An end-of-life default tells you how much attention the platform gets.
• How much notice before a forced upgrade? Forced upgrades are correct policy; no warning is not.
• Can I roll back if it breaks? A one-click revert buys the confidence to actually try.
• Do you patch PHP yourselves, or track the distribution package? Relevant if you rely on backported fixes.

Practice varies a great deal. Compare what is on offer in web hosting and WordPress hosting before you commit — and if you run your own stack on VPS hosting, all of the above is your responsibility.

FAQ

Which PHP version should I be on right now?

PHP 8.4 for most production sites — active support until 31 December 2026, broad plugin compatibility. PHP 8.5 if your stack is already tested against it. PHP 8.3 is acceptable but already security-only.

Is PHP 8.2 still safe?

It receives critical security fixes until 31 December 2026 and nothing else. Safe for now, on a deadline you should already be planning around.

My host only offers PHP 8.1 or older. What should I do?

Move. A host that cannot offer a supported PHP branch in mid-2026 is not maintaining its platform, and PHP is unlikely to be the only thing it has stopped updating.

Will upgrading PHP break my site?

Between adjacent 8.x releases, rarely — and when it does, the cause is usually an unmaintained plugin. Crossing from 7.x to 8.x is a genuine migration that needs staging and testing.

How do I know when my version expires?

Check php.net/supported-versions once a year. It is authoritative and the dates are set years in advance.

What to do next

Check the PHP version behind your site today and compare it against the table above. If it is 8.1 or older, treat that as a live security issue rather than a maintenance item. If it is 8.2, put 31 December 2026 in the calendar now.

And when you next price hosting, weigh the PHP support policy alongside the number on the pricing page. Our guide on how to compare hosting prices without getting misled makes the same point about a different line item: a plan that has stopped investing in its platform is not actually the cheap one.

Sources

• PHP — Supported Versions and Unsupported Branches
• WordPress — Requirements
• WordPress — Statistics (PHP version distribution)
• PCI Security Standards Council — PCI DSS v4.0 requirement 12.3.4