PHP end of life: dates for every version, and what to do about yours

Each PHP release branch now gets two years of full support, with bug and security fixes, then two more years of critical security fixes only. After that it reaches end of life and gets nothing (php.net: supported versions). The four-year cycle and the December 31 end dates come from a 2024 change to PHP's release policy, which added a year of security support and gave PHP 8.1 an extra year (PHP RFC: release cycle update).

Check which PHP version your site reports →

PHP end-of-life dates

Dates from php.net: supported versions, php.net: unsupported branches and the PHP changelogs. PHP 8.6 is in release-candidate testing and has no release date yet.

What end of life means

The PHP project puts it plainly: users of an end-of-life release "should upgrade as soon as possible, as they may be exposed to unpatched security vulnerabilities" (php.net). When a new flaw is found, the supported branches get a fix and the end-of-life ones usually don't.

PHP2Shell, the critical flaw disclosed in October 2026, is the example. PHP's advisory fixed it in 8.2.35, 8.3.36, 8.4.27 and 8.5.12, offered only minimal source patches for 7.4, 8.0 and 8.1 for people who build PHP themselves, and nothing for older versions. It noted that "PHP 8.1 and older no longer receive updates from the PHP project" (php.net security advisory, October 21, 2026). See our PHP2Shell guide for what to do.

"End-of-life version of PHP detected": the scanner finding

If you've had a security scan, a penetration test or a customer's vendor review, you may have seen a finding like one of these:

• Tenable Nessus 58987, "PHP Unsupported Version Detection", rated Critical (Tenable).
• Tenable Web App Scanning 98230, "PHP Unsupported Version", and 98239, "PHP Version End of Life Advanced Notification", an early warning that your version is about to reach end of life (Tenable).
• Invicti and Acunetix, "Out-of-date Version (PHP)" (Invicti).
• Qualys, "EOL/Obsolete Software: PHP … Detected", for example QID 150522 for PHP 5.x (Qualys).

All of these work from the version number your server reports. That's usually right, but there's one important exception.

When an "end-of-life" PHP is actually patched

Linux distributions often keep shipping the PHP version they launched with and backport security fixes into it, without changing the version number. Debian's security FAQ says so directly: "Instead of upgrading to a new release we backport security fixes to the version that was shipped in the stable release" (Debian). Some examples:

• Ubuntu 22.04 ships PHP 8.1.2 and published a security update for it on October 21, 2026, nearly ten months after PHP 8.1's end of life. Its standard support runs to May 2027 (Launchpad, Ubuntu release cycle).
• Red Hat Enterprise Linux supports PHP 8.2 in RHEL 8 and 9 until May 2029, and PHP 7.4 as part of RHEL 8 for that release's full life (Red Hat Application Streams life cycle).
• Debian 12 ships PHP 8.2 and includes the October 2026 fixes in its security repository (Debian security tracker).

So the finding needs one of two answers: proof that the package is a vendor-supported build with current backports (the package version and the vendor's lifecycle page), or an upgrade. On shared or managed hosting, ask the host. A cPanel host that offers end-of-life PHP versions may rely on a paid extended-support vendor; cPanel itself only builds versions php.net supports (cPanel: about PHP).

How to upgrade PHP safely

1. Find your current version. Use our PHP vulnerability checker, your host's control panel, or WordPress's Site Health screen. See what PHP version is my site running.
2. Pick a target with time left. PHP 8.4 or 8.5 for new work, 8.3 at minimum. WordPress recommends PHP 8.3 or greater (WordPress requirements).
3. Update the application first. Bring WordPress or your CMS, themes and plugins up to date, since older code is what breaks on newer PHP.
4. Test on a copy. Switch a staging copy to the new version and test key pages, forms, checkout and admin. Turn on error logging to catch warnings.
5. Switch production in your host's PHP selector, such as cPanel's MultiPHP Manager (cPanel docs), then test again. Host-specific steps: WordPress, cPanel, GoDaddy.
6. Hide the version afterwards so the server doesn't advertise it: see hide your server and PHP version.

What tends to break when moving from PHP 7 to 8

• Comparisons between strings and numbers changed in PHP 8.0: 0 == "foo" is now false.
• Many warnings became errors, and the @ operator no longer hides fatal errors.
• Removed functions such as each() and create_function(), common in old plugins.
• Database errors now throw exceptions by default: PDO from 8.0, MySQLi from 8.1.
• Passing null to built-in functions that don't accept it is deprecated from 8.1, which fills logs on older code.

Details are in PHP's migration guides for 8.0, 8.1, 8.2, 8.3, 8.4 and 8.5.

Sources

• php.net: supported versions and unsupported branches
• PHP RFC: release cycle update (accepted April 2024)
• php.net security advisory, October 21, 2026
• Tenable: PHP Unsupported Version Detection, Invicti: Out-of-date Version (PHP)
• Debian security FAQ, Ubuntu release cycle, Red Hat Application Streams life cycle
• WordPress requirements, cPanel: about PHP

Common questions

Got a scan finding or a PHP version that's running out? We confirm what your server really runs, upgrade it, test the site and keep it on a supported version from then on, for one site or many. See website maintenance and security or security audits, book a free discovery call or call (914) 222-3310.