PHP End of Life (EOL)

Many websites, shops, and line-of-business applications run unchanged for years, and the PHP version underneath ages with them. At the latest with the end of life, that is, the end of support, this becomes a security problem: newly discovered vulnerabilities are no longer fixed in this version. The PHP project explicitly advises upgrading from unsupported versions to a current version as soon as possible, because otherwise unpatched security vulnerabilities are a risk.

The PHP support cycle

According to php.net, the following applies to every PHP release branch:

1. Active support, two years from release: Reported bugs and security issues are fixed and published in regular maintenance releases.
2. Security support, two further years: Only critical security issues are fixed, and releases are made as needed.
3. End of life: Support ends after a total of four years. For all currently supported versions, the periods each end on December 31

Support periods at a glance

As of October 25, 2026, according to the overviews on php.net:

• PHP 8.5: released on November 20, 2025, active until December 31, 2027, security updates until December 31, 2029
• PHP 8.4: released on November 21, 2024, active until December 31, 2026, security updates until December 31, 2028
• PHP 8.3: released on November 23, 2023, security updates until December 31, 2027
• PHP 8.2: released on December 8, 2022, security updates until December 31, 2026
• PHP 8.1: end of life since December 31, 2025, last version 8.1.34
• PHP 8.0: end of life since November 26, 2023
• PHP 7.4: end of life since November 28, 2022

If you still run PHP 8.2 today, you therefore only have security updates until the end of the year. For upgrades to a new version, planning over several months is worthwhile.

What end of life means in practice

• No more fixes: New vulnerabilities remain open, including critical ones.
• Libraries follow suit: Frameworks and packages end support for old versions. Laravel 13, for example, requires at least PHP 8.3, see Laravel.
• Obligations and evidence: The NIS2 Directive requires affected entities to take measures for handling vulnerabilities. The GDPR requires security in line with the state of the art. A known, unsupported version is hard to justify in this context.
• Discoverability: If a server discloses its version in the X-Powered-By header, an outdated installation can easily be detected from the outside. The Security Header Check in the TOMORIS Toolbox shows such information.

Special case: Linux distributions

Linux distributions such as Red Hat Enterprise Linux often ship PHP in an older version and retroactively apply security fixes from newer versions to their package. Red Hat calls this backporting and points out that the version number alone then does not show whether a system is vulnerable. In this case, what matters is the support period of the distribution, not that of php.net. With hosting offers, it is worth checking which versions the provider maintains and for how long.

How to plan the upgrade

1. Take inventory: List all servers, hosting packages, containers, and command-line jobs with their PHP version, for example with php -v.
2. Check compatibility: The migration notes on php.net list changed and removed features for each version. Static analysis tools find affected places in the code.
3. Update dependencies: Use Composer to check which packages support the target version.
4. Test: Test in a test environment with automated tests and business acceptance, ideally via a CI/CD pipeline.
5. Switch over and observe: Switch over in stages, monitor error logs for deprecation warnings, and keep a way back ready.
6. Repeat: Include PHP versions in patch management and vulnerability management, and plan the next switch in good time.

How it differs

A security update within a version, for example from 8.4.x to a newer 8.4 version, is a regular patch. Switching to a new version, for example from 8.2 to 8.4, is an upgrade with adjustments and tests. End of life concerns the PHP runtime. Applications and frameworks have their own support periods, which are often shorter.

Sources

• php.net: Supported Versions (accessed October 25, 2026)
• php.net: Unsupported Branches (accessed October 25, 2026)
• php.net: Migrating from PHP 8.4.x to PHP 8.5.x
• Red Hat: Backporting Security Fixes
• EUR-Lex: Directive (EU) 2022/2555 (NIS2), Art. 21
• EUR-Lex: Regulation (EU) 2016/679 (GDPR), Art. 32
• Laravel: Release Notes 13.x, Support Policy