PHP End of Life Dates (2026): Which PHP Versions Are Still Supported
Every PHP branch with its end-of-life date, what end of life really means for a live site, and a practical order for upgrading from PHP 7.4, 8.1 or 8.2.
SiteXray
A PHP version reaches end of life (EOL) when the PHP project stops publishing security fixes for it. The site keeps working, which is exactly why so many servers stay on old versions for years. But the next critical bug is never fixed for you, and October 2026 showed what that looks like: the PHP2Shell remote code execution bugs were patched in 8.2 through 8.5, while 8.1 and everything older got no official fix at all.
PHP support dates
Since PHP 8.1 the project gives each branch two years of active support and two years of security-only support, ending on December 31.
| Version | Released | Security support ends | Status (Oct 2026) |
|---|---|---|---|
| PHP 8.5 | Nov 2025 | Dec 31, 2029 | Supported |
| PHP 8.4 | Nov 2024 | Dec 31, 2028 | Supported |
| PHP 8.3 | Nov 2023 | Dec 31, 2027 | Security fixes only |
| PHP 8.2 | Dec 2022 | Dec 31, 2026 | Security fixes only, ends in weeks |
| PHP 8.1 | Nov 2021 | Dec 31, 2025 | End of life |
| PHP 8.0 | Nov 2020 | Nov 26, 2023 | End of life |
| PHP 7.4 | Nov 2019 | Nov 28, 2022 | End of life |
| PHP 7.3 and older | End of life |
The official source is php.net/supported-versions. Dates in this table were checked on October 21, 2026.
What end of life means in practice
- No security patches. When a bug like PHP2Shell lands, supported branches get a release the same day. EOL branches get nothing.
- Frameworks move on. Current Laravel, Symfony and WordPress plugin releases drop old PHP versions, so you are also stuck on old, unpatched application code.
- Your host may force the issue. Shared hosts and panels routinely remove EOL PHP builds or charge extra for "extended support".
- "Extended support" is a product, not a patch policy. Vendors such as distributions or commercial backport services can keep a branch patched for a fee. That is a valid stop-gap, but check exactly which CVEs they cover.
Is my site on an end-of-life PHP version?
On the server, php -v gives the CLI version; check the web server's version separately in your hosting panel or via the FPM binary. From the outside, many servers leak it in a response header:
curl -sI https://example.com | grep -i x-powered-by
The website vulnerability scanner checks that header against the table above and flags EOL and PHP2Shell-vulnerable versions automatically.
Upgrade order that causes the least pain
- Get to a supported branch first, then to the latest. From 7.4, going to 8.3 is usually less work than you fear; most breakage comes from removed functions and stricter type handling, which static analysis finds before your users do.
- Run your test suite and a static analyser (PHPStan or Psalm) against the target version. Add the PHPCompatibility ruleset for PHP_CodeSniffer to list deprecated calls.
- Update dependencies with Composer while still on the old version, as far as they go, then switch PHP and update again.
- Upgrade a staging copy, click through checkout, login and forms, and read the error log.
- Switch production and restart PHP-FPM. Keep the previous PHP package installed for a quick rollback.
If you are on PHP 8.2, plan the move to 8.4 now: security support ends on December 31, 2026, and the next critical fix after that will not reach you.
After the upgrade
Set expose_php = Off so the version stops appearing in headers, then re-scan the site. Need help with a legacy codebase? The fix sprint includes an upgrade plan, and managed patching keeps the server on supported versions afterwards.