Every time a critical PHP vulnerability makes the rounds — most recently the PHP2Shell vulnerability — the same line shows up in the advisory: end-of-life branches get no official fix. This post covers both halves of that problem: what PHP’s end-of-life process actually means and why EOL branches stay in production for years past their support window, and how to build a repeatable patch workflow so staying current isn’t a fire drill every time a new CVE lands.
What “end-of-life” means for PHP
Each PHP branch (8.4, 8.3, 8.2, and so on) goes through two support phases before it is retired:
- Active support (2 years) — bug fixes and security fixes.
- Security support (1 additional year) — security fixes only, no bug fixes.
- End of life — no fixes of any kind from the PHP project, for any issue, including remotely exploitable ones.
That gives every branch roughly three years of upstream support from its initial release. After that date passes, the PHP project will not backport a patch for a new CVE to that branch, no matter how severe. The 8.1.2-1ubuntu2.28-style version strings you see in distro changelogs are downstream backports from a vendor’s own security team, not upstream PHP continuing to maintain the branch — once a branch is EOL upstream, every fix you get from then on comes from your distro, not the PHP project.
Current PHP branch status
| Branch | Initial release | Active support ends | Security support ends |
|---|---|---|---|
| 8.5 | Nov 2026 | Nov 2028 | Nov 2029 |
| 8.4 | Nov 2024 | Nov 2026 | Nov 2027 |
| 8.3 | Nov 2023 | Nov 2025 | Nov 2026 |
| 8.2 | Dec 2022 | Dec 2024 | Dec 2025 |
| 8.1 | Nov 2021 | Nov 2023 | Nov 2024 (EOL) |
| 8.0 | Nov 2020 | Nov 2022 | Nov 2023 (EOL) |
| 7.4 | Nov 2019 | Nov 2021 | Nov 2022 (EOL) |
Branches 7.3 and earlier, including the entire 5.x and 7.0–7.2 lines, have been EOL for years. If php -v on one of your hosts reports anything in that range, it is not receiving fixes from upstream PHP under any circumstance.
Why EOL PHP keeps running in production
EOL branches rarely survive by decision — they survive by default. The usual causes:
- Framework and plugin lock-in. A WordPress plugin, a Laravel app on an old major version, or an in-house codebase that calls deprecated functions removed in later PHP versions blocks the upgrade path until someone budgets time to fix the calling code.
- Distro-extended support masking the real status. Debian LTS, Ubuntu ESM, and RHEL’s extended lifecycle backport security fixes onto EOL PHP branches for years past their upstream EOL date. That buys time, but it is not the same as the branch being supported — those distro backports only cover issues the vendor chooses to patch, and coverage quietly thins out as the branch ages.
- No ownership. On servers nobody is assigned to, PHP upgrades fall under “if it isn’t broken” until an incident like PHP2Shell makes it broken.
- Fear of breaking changes. Each major PHP version removes deprecated functionality (e.g.
mysql_*functions removed in 7.0, dynamic class properties deprecated in 8.2). Teams defer the upgrade rather than spend the time auditing for breakage.
Finding EOL PHP across your fleet
Before you can retire anything, you need an inventory. On each host:
php -v
php -i | grep -i 'php version'
rpm -qa 'php*' 2>/dev/null || dpkg -l 'php*' 2>/dev/nullIf you are managing more than a handful of hosts, script the collection instead of checking each one by hand — an Ansible ad-hoc command or a one-line SSH loop over your inventory will surface every branch in use far faster than logging into each box:
ansible all -m shell -a "php -v | head -1"A single php -v is not sufficient on hosts using Remi’s versioned packages. The remi-safe repository is designed to let multiple PHP branches coexist side by side — each versioned package (e.g. php74-php-fpm, php81-php-fpm, php82-php-fpm) installs its own binaries under /opt/remi/phpNN/ and runs as its own service, independently of whichever version /usr/bin/php points to. php -v only reports that one default binary; it says nothing about the other installed branches, and says nothing about which of them are actually enabled and serving requests. On a Remi host, enumerate every installed version and every running instance separately:
rpm -qa 'php[0-9][0-9]-php-fpm' 'php[0-9][0-9]-php-cli'
for v in /opt/remi/php*/root/usr/bin/php; do echo "$v:"; "$v" -v | head -1; done
systemctl list-units --all 'php*-fpm*'The first command lists every versioned branch installed on the box; the second prints the actual version string for each one (don’t assume the package name’s version suffix matches the patch level); the third shows which of those FPM instances are enabled or actively running, independent of which one the default php command invokes. A branch can be both installed and actively serving traffic through its own FPM pool while remaining completely invisible to a plain php -v check.
Cross-reference every version you find — from every one of these commands, not just the default binary — against the table above. Anything past its security support end date is running without an upstream safety net, whether or not it’s the version php -v happens to report.
Getting off an EOL branch
- Target the nearest supported branch, not the newest. Jumping from 7.4 straight to 8.5 compounds every breaking change across five major versions at once. Move one or two majors at a time and test at each step.
- Run the branch’s migration guide. The PHP manual publishes a “Backward Incompatible Changes” page for every major version — read the one for each version you are passing through, not just the destination.
- Use static analysis to find breakage before runtime does. Tools such as PHPCompatibility (a PHP_CodeSniffer ruleset) flag calls to removed or deprecated functions against a target PHP version without executing the code.
- Stand up the new version in parallel, not in place. Run the target PHP version alongside the old one (separate FPM pool, separate container, or a canary vhost) and route a slice of traffic to it before cutting over fully.
- Re-point package management at a maintained source if your distro’s default repo lags. RHEL-family systems commonly rely on the Remi repository for current PHP versions; Debian and Ubuntu’s default repos track one branch per release, so a distro upgrade may be required to reach a newer branch.
Once you’re current: a repeatable patch workflow
Landing on a supported branch solves today’s problem. Keeping it supported is an ongoing task. The pattern that keeps a routine patch cycle from turning into an incident response is: know your branch, hear about advisories quickly, patch by a known-good procedure, and verify the fix actually landed.
Know your branch and its support window
Check the running version and cross-reference it against the PHP supported versions page, noting the branch (the first two numbers, e.g. 8.3), not just the full version string — security fixes apply per branch, and a branch past its security support end date will not receive a fix for a new CVE regardless of how recent its last patch was:
php -vOn hosts running multiple Remi-packaged branches side by side, php -v only covers the default binary — see the fleet-inventory commands above for enumerating every installed and running version before you decide what needs patching.
Subscribe to the sources that announce PHP security releases
You want to hear about a critical PHP CVE within hours, not when a scanner flags it weeks later:
- PHP’s own security advisories — the php.net front page and the
php-announcemailing list cover every security release. - Your distro’s security advisory feed — Debian Security Advisories (DSA) and Long Term Support Advisories (DLA), Ubuntu Security Notices (USN), and RHEL/AlmaLinux/Rocky errata (ELSA/RHSA) all publish per-package advisories you can subscribe to or pull via
dnf updateinfo. - CISA’s known exploited vulnerabilities catalog — flags when a CVE moves from “patch when convenient” to “patch today” because active exploitation has been confirmed.
Patching, by distribution
The commands differ by distro, but the pattern is the same: refresh metadata, upgrade the PHP packages, restart the services that embed PHP.
RHEL, AlmaLinux, Rocky Linux (8, 9, 10):
sudo dnf clean metadata
sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm httpdList pending security errata specifically, rather than upgrading everything, if you want to patch PHP in isolation:
sudo dnf updateinfo list security | grep -i phpIf you installed PHP from the Remi repository (common on RHEL-family boxes to get a PHP version newer than the distro default), package names are prefixed per version, e.g. php84-php-fpm:
sudo dnf upgrade 'php84-*'
sudo systemctl restart php84-php-fpmDebian:
sudo apt update
sudo apt install php
sudo systemctl restart php-fpm apache2Debian ties its PHP branch to the release (bookworm ships 8.2, trixie ships 8.4). A distro upgrade, not just a package upgrade, is required to move to a newer branch. Debian LTS extends security coverage for the previous stable release; check whether your release is still inside that window.
Ubuntu:
sudo apt update
sudo apt upgrade
sudo systemctl restart php-fpm apache2As with Debian, the PHP branch is tied to the Ubuntu release. Older LTS releases (14.04, 16.04) only continue receiving PHP security fixes under Ubuntu Pro with esm-infra enabled — verify that subscription is active if you depend on it.
Automating the check, without automating the restart
Checking for pending PHP security updates is safe to automate; applying them to a production web server mid-request is not. A reasonable split:
- Automate detection. A daily cron job or CI check that runs
dnf updateinfo list security/apt list --upgradableand alerts (Slack, email, a monitoring check) when a PHP package has a pending security update. - Automate staging rollout. Apply the update to a staging or canary host automatically, run your test suite against it, and only then queue the production rollout.
- Keep production patching a deliberate, scheduled action — a maintenance window or a rolling restart across your pool — so a patch doesn’t land mid-traffic-spike and so you control the order services restart in.
Verifying a patch actually landed
Most enterprise distros backport the security fix into the existing package version rather than bumping the upstream version number, so php -v can keep showing the same string before and after you’ve patched. Don’t use the version string alone to confirm a fix:
- Check the package’s installed version against the distro advisory’s “fixed in” version, e.g.
rpm -q phpordpkg -s php8.2-fpm | grep Versioncompared against the advisory. - Read the advisory’s changelog entry for the CVE ID directly — it will name the exact package version that contains the fix.
- For a configuration-level mitigation (rather than a package patch), confirm the live setting with
php -i | greporphpinfo()against a running worker, not just the config file on disk — a worker that hasn’t restarted is still running the old setting.
Summary
- PHP branches get roughly three years of upstream support total, then no fixes of any kind, for any severity.
- Distro-extended support (Debian LTS, Ubuntu ESM, RHEL ELS) can mask how old a branch really is — check the upstream EOL date, not just whether patches are still arriving.
- Inventory every host’s PHP version, prioritize anything past security support end-of-life, and migrate one major version at a time with static analysis and parallel testing.
- Once current, know your branch’s support window, subscribe to advisory feeds, automate detection of pending updates, and verify fixes against the distro advisory rather than an unchanged version string.
- Treat every PHP2Shell-style incident as a forcing function, not a one-off, until EOL branches are actually gone from your fleet and patching is routine rather than reactive.
