PHP supported versions in 2026: which branches still get security fixes and what to do

Most company websites run on PHP without anyone thinking about it: WordPress, most online shops and most agency-built sites sit on a version the hosting provider chose years ago. That version has an expiry date. This guide lists the dates as php.net publishes them, shows how to find your own version and gives an order for moving to a supported branch.

How PHP support works

The PHP project states the rule on its supported versions page: each release branch is fully supported for two years from its initial stable release, during which reported bugs and security issues are fixed; after that it is supported for two additional years for critical security issues only.

Once the four years are over, the branch reaches its end of life and is no longer supported; the same page says users of such a release should upgrade as soon as possible, as they may be exposed to unpatched security vulnerabilities.

A site on an end-of-life branch keeps working, but a vulnerability found tomorrow is fixed for the newer branches, not for yours.

PHP branches that still receive fixes

All dates are from php.net, read on 2026-10-24.

8.2 and 8.3 are already in the security-fixes-only phase; a site on 8.2 has until 31 December 2026, so plan the move now, not in December.

PHP branches that are end of life

The unsupported branches page lists the date and the last release of every branch that no longer receives any fixes. The most recent ones:

7.4 has had no fixes for almost four years, yet it is the branch we met most often among end-of-life sites.

How to see which PHP version your site runs

You do not need a developer for the first check:

1. Hosting panel. Most control panels have a PHP version selector per domain; if you cannot find it, ask the provider.
2. WordPress Site Health. Tools → Site Health → Info has a Server section with, in the words of the WordPress documentation, information about the server architecture, the web server and various PHP variables; the Status tab of the same screen warns when the site is running an outdated version of PHP.
3. A phpinfo file. A developer can place a one-line file calling phpinfo() on the server and open it in a browser. Delete it immediately afterwards: it shows your whole configuration to anyone who finds it.
4. The response header. Open your own site in the browser's developer tools and look at the response headers. A line such as X-Powered-By: PHP/7.4.33 is your version, visible to everyone who asks.

Check every site and subdomain the company owns; forgotten campaign and test sites are usually the oldest.

Why the X-Powered-By header should be hidden

The php.net manual describes expose_php as a directive that exposes to the world that PHP is installed on the server, including the PHP version within the HTTP header, with the example X-Powered-By: PHP/5.3.7. Its default value is on, and it can only be changed in php.ini.

The manual's own Hiding PHP page is honest about the limits: security by obscurity is one of the weakest forms of security, but in some cases every little bit of extra security is desirable, and setting expose_php to off in php.ini reduces the amount of information available to an attacker trying to discover weaknesses.

Hiding the header does not make an end-of-life PHP safe; it only stops you from advertising it. Upgrade first, then hide the header; if you cannot edit php.ini, ask the provider. Our sample exists only because 124 sites left this header on.

What breaks when you upgrade

Each new branch removes or changes something. php.net publishes a migration guide for every step, each with a Backward Incompatible Changes section, listed on the appendices page. A site moving from 7.4 to 8.3 crosses four guides; the 7.4 to 8.0 step most often breaks old code.

For WordPress the application itself is rarely the problem. The wordpress.org requirements page recommends PHP 8.3 or greater and says WordPress also works with PHP 7.4 and later, noting that those versions have reached their official end of life and may expose the site to security vulnerabilities.

What breaks is the long tail around it:

• Plugins and themes written for PHP 7 and never updated. The WordPress plugin directory shows each plugin's required PHP version and last update; one not updated for years is the first suspect.
• Custom code an agency wrote years ago: a child theme, a contact form, an integration with the accounting system.
• Old shop platforms that themselves support only PHP 7 need a platform upgrade first.

The failure is rarely subtle: a fatal error turns a page white. That is why you test on a copy.

A migration order that works

1. Inventory. List every site, its PHP version, its CMS and who maintains it. Mark which are on 8.1 or older (no fixes now) and which on 8.2 (no fixes after 31 December 2026).
2. Update the application first. Bring WordPress, every plugin and the theme to their current versions. A plugin that cannot be updated is replaced, not carried over.
3. Pick the target. For WordPress, 8.3 or newer, as wordpress.org recommends. Prefer the branch with the longest remaining support that your software accepts: 8.4 gives fixes until 31 December 2028.
4. Test on a copy. Most hosting panels can create a staging copy; switch it to the target branch, click through the shop, the forms and the admin area, and read the error log. Fix or replace what fails.
5. Switch production in a quiet hour, with a way back: the panel lets you select the previous version again.
6. Watch the logs for a few days, then turn expose_php off, or ask the provider to.
7. Put the next date in the calendar. The branch you chose has an end date on php.net; the move is a recurring task, not a one-off project.

Where this fits in a company's security

An end-of-life PHP branch is one of the simplest things to find from outside and to fix, which makes it a good first task. It is also a symptom: a site whose runtime nobody has touched for four years usually has plugins in the same state, and plugin advisories arrive weekly.

The same expiry logic applies to other runtimes, as the Node.js Brotli vulnerability showed.

Northwestern Tideline keeps this list for a company: which runtimes and components it depends on, when each stops receiving fixes, and which published advisory touches which site, with a human reading the result before anything is done. We look only at what a company asks us to look at, in writing.

The overview is on the Tideline page and in our guide to cybersecurity for companies in the age of AI. If you want your sites' PHP versions checked and a migration plan written down, send us the list of domains.

This guide describes the php.net schedule and a general procedure, not your hosting contract or your software.