PHP End of Life - Dates and Lifecycle

First released in 1995, PHP now runs on the majority of websites with a known server-side language, powering everything from WordPress and Drupal installations to enterprise platforms handling billions of requests a day. That scale of deployment is exactly what makes PHP end of life dates matter. The W3Techs usage statistics report shows that PHP is used by more than 70% of all websites as a server-side programming language. It also shows that PHP version 7.x is still used by 30% of all those PHP-based websites. This is a huge number of production systems running a branch that has not received security patches for years.

PHP Support Lifecycle Explained

Each PHP release branch gets four years of official support, split into two phases. The first two years are Active Support: the branch receives regular point releases with both bug fixes and security patches. The next two years are Security Support: only critical security issues get patched, releases are irregular and issued only as needed, and there are no more bug fixes or compatibility updates. After four years, the branch reaches End of Life and receives nothing further, regardless of severity.

This four-year window is a March 2024 extension of PHP's previous three-year policy (2 years active + 1 year security). Only PHP 8.1 and later fall under the extended cycle; older branches kept their original three-year lifespan. PHP ships one new feature version per year, typically in November, so three or four versions are usually in active or security support at once.

Security Risks of Running EOL PHP

Once a PHP version reaches end of life, the PHP project stops shipping updates of any kind for it, including fixes for newly disclosed vulnerabilities. Any CVE found in an EOL branch after that date stays open indefinitely, and PHP does see regular CVE activity: 15 vulnerabilities were disclosed in 2025, and 15 more have already been found in 2026, with only supported branches receiving fixes. The average severity has climbed too, this year's vulnerabilities are scoring notably higher on average than last year's, which raises the stakes for anything left unpatched. Running an EOL version doesn't stop an application from working, but it does mean the runtime underneath it is an unpatched, permanently open attack surface.