PHP End-of-Life Schedule & Security Implications
debt(d5/e7/b5/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list rector and lynis — both are specialist tools (a code-modernisation tool and a system auditing tool respectively) that must be deliberately run. The version can also be spotted via `php -v` or X-Powered-By headers, but none of this is surfaced by a default linter in the normal development workflow, pushing it past d3.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix says to use Rector for an upgrade, but upgrading from an EOL PHP version (e.g. 5.6 or 7.x) to a supported version touches every file that uses deprecated or removed syntax, requires dependency compatibility checks across all packages, and typically spans the entire codebase plus deployment/infrastructure configuration. This is more than a single-component refactor, landing firmly at e7.
Closest to 'persistent productivity tax' (b5). The applies_to covers web, cli, and queue-worker contexts — essentially all PHP execution contexts. Running on an EOL version imposes a constant compliance and security overhead, blocks library upgrades (many modern packages drop EOL PHP support), and affects every developer and deployment pipeline, but it does not architecturally dictate every individual code change the way a b7 choice would.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The misconception field states exactly this trap: developers believe an EOL version is safe if no known exploits currently target it. This contradicts the security model of actively maintained software and is a well-documented but widely held wrong belief. New CVEs accumulate silently, making the 'no known exploit' assumption dangerously false — a serious cognitive trap scoring t7.
Also Known As
TL;DR
Explanation
The PHP release cycle: each new minor version gets 2 years of active support with bug fixes and security patches, followed by 1 year of security-only support, then end-of-life. After EOL, when a CVE is discovered for that PHP version, no patch will be released. The attacker knows which version you are running via X-Powered-By header or phpinfo(), knows the CVE exists, and can exploit it with a public PoC. The PHP EOL schedule is published at https://www.php.net/supported-versions.php.
Common Misconception
Why It Matters
Common Mistakes
- Running PHP 5.6 or 7.x years after EOL with no upgrade plan
- Assuming shared hosting will notify you when PHP goes EOL
- Not testing against the latest PHP version proactively
Code Examples
# Running PHP 7.4 (EOL Dec 2022) in production — no security patches:
# php --version
# PHP 7.4.33 (cli)# Check EOL status: php.net/supported-versions
# Upgrade path: 7.4 → 8.1 → 8.3
# php --version
# PHP 8.3.x (cli) — Active support until Nov 2026