Why End-of-Life PHP Versions Need a Retirement Plan

End-of-life PHP versions are branches the PHP project no longer patches, and in October 2026 that means PHP 8.1 and everything older. When a critical runtime flaw lands, as the PHP2Shell vulnerabilities did on October 21, those servers get no official release. With PHP 8.2 reaching end of life on December 31, 2026, every team running PHP needs a dated plan to retire old branches before the next emergency.

What does end of life mean for PHP?

End of life means the PHP project has stopped publishing releases for that branch, including security fixes. PHP 8.1 and older no longer receive updates from the project, and PHP 8.2 joins them on December 31, 2026.

Some Linux distributions and commercial LTS vendors keep backporting fixes to old branches for their own packages. That support is real, but it covers only their builds, on their timeline, for the issues they choose to fix.

How big is the end-of-life PHP problem?

Very large. In data cited by Recorded Future, Modat counted 4,384,302 internet-facing PHP services, and about 79% of those that disclose a version run unsupported branches. PHP 7.4 alone accounted for 878,761 services.

VirusTotal's numbers point the same way: of roughly 1.1 million PHP hosts that disclose a version, about 758,000 run end-of-life branches from 5.4 to 8.1, against about 272,000 on supported ones.

Why end-of-life PHP versions are a security risk

The PHP2Shell response shows what happens on an old branch during a crisis.

• No release to install. The supported branches got 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For 7.4, 8.0 and 8.1, the PHP project published minimal source backports for people who build PHP themselves. If you install PHP from packages, that does not help you.
• Dependency on someone else's schedule. If a distribution or LTS vendor backports the fix, you wait for their package. If you used a third-party repository or a vendor appliance that bundles PHP, you may not know whether a fix exists at all.
• Mitigations are partial. The PHP advisories say there are no complete configuration mitigations for either CVE. Settings such as disabling session upload progress reduce exposure but leave paths open, so an unpatchable server stays exposed.
• Scanning favors old versions. Many sites expose their PHP version in response headers. Attackers can sort targets by version as easily as defenders can.

Recorded Future also notes that older unsupported branches should not be assumed safe just because advisories list only the current branches as affected. The vulnerable code paths are often older than the supported branches.

Build an inventory first

You cannot retire what you cannot find. A PHP inventory needs more than the package list on your web servers.

1. Web servers and VMs: every PHP version installed, which SAPI each site uses and who owns each site.
2. Containers: base images that ship PHP, including images built years ago and never rebuilt.
3. Appliances and products: monitoring tools, control panels, help desks, wikis and vendor appliances that bundle their own PHP. Recorded Future specifically calls out PHP bundled in third-party apps, containers and managed services.
4. Managed hosting: which PHP version your provider runs for each site, and whether you or they control upgrades.

Record the branch, its end-of-life date and the business owner for each entry. The owner is the person who signs off on the upgrade or accepts the risk.

Set a retirement plan with dates

Treat each end-of-life branch as a project with a deadline, not a backlog item.

• Now: anything on 8.1 or older that faces the internet gets either a supported vendor backport or a migration date this quarter. Put it behind a WAF and restrict access until then.
• Before December 31, 2026: every PHP 8.2 site gets tested and moved to 8.3 or newer. Starting in the last two weeks of December is how a server ends up unsupported in January.
• Every year: schedule a branch upgrade as routine maintenance. PHP branches have a fixed support life, so the dates are known well in advance.

Application compatibility is the usual blocker. Old plugins, abandoned frameworks and custom code written for PHP 5 or 7 can break on 8.x. Budget the code work, and where an application cannot be updated, plan to replace or decommission it.

When an old branch cannot move yet

Some systems will miss the deadline. For those, reduce what an attacker can do while the migration is pending.

• Remove direct internet exposure, or limit access to known networks and a VPN.
• Disable features you do not use, starting with session upload progress, as described in how to disable PHP session upload progress.
• Move off mod_php where you can, since it was the highest-risk setup for PHP2Shell; see mod_php vs PHP-FPM and why the SAPI changes your risk.
• Run the site under a low-privilege account that cannot read other sites or secrets.
• Record a formal risk acceptance with an owner and an expiry date, so the exception does not become permanent.

For other software past its support date, the same pattern applies; our article on vendor security advisory subscriptions covers how to hear about the next emergency release early.