I have a client whose invoicing app still runs PHP 7.4. I’ve been asking to upgrade it for two years. The answer is always the same: it works, so leave it. On October 21 that answer got a lot harder to defend, because the PHP2Shell fixes shipped for 8.2 through 8.5, and the old branches live in a murkier place.<\/p>\n
Short version for the impatient: if you run PHP 7.4, 8.0 or 8.1, a patched build exists but it carries the same version number as the vulnerable one, so If you’re on a supported branch, my PHP 8.5.12 patch checklist<\/a> is the better starting point. This post is about the PHP end of life problem.<\/p>\n The fixed versions for supported branches are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Those are the easy ones.<\/p>\n The older branches are where it gets strange. According to Plesk’s patch summary<\/a>, PHP 8.1, 8.0 and 7.4 are fixed in builds dated October 21, 2026, and those builds keep the version numbers 8.1.34, 8.0.30 and 7.4.33. Plesk marks those three as Linux only. PHP 5.6, 7.2 and 7.3 are not patched.<\/p>\n Rapid7<\/a> describes the 7.4, 8.0 and 8.1 fixes as limited source backports supplied by the PHP project. watchTowr<\/a> adds two points: there is “no official release” for those three branches, and PHP 7.3 and older have no fix available but are confirmed affected.<\/p>\n So the state of the world is this. 7.4, 8.0 and 8.1 can be patched if someone builds or ships a backport. 7.3 and below can’t be patched by anyone except a paid extended support vendor.<\/p>\n I’ll admit that last part annoys me. Plesk’s article recommends TuxCare Extended Lifecycle Support for the unpatched branches, which is a reasonable thing to mention, but it also means the fix for abandoned PHP is a subscription. Whether that’s worth paying depends on how long you plan to stay on the old version, and I’d put a hard date on it before signing anything.<\/p>\n Here’s the trap. The vulnerable 8.1.34 and the patched 8.1.34 print the same thing.<\/p>\n If that build line says October 21, 2026 or later, you have the fix. If it says anything earlier, you don’t, even though the version looks identical. Plesk’s article describes the same check: the patched 8.3 build should report 8.3.36 with a build date of Oct 21 2026, and EOL branches should be checked by build date for the same reason.<\/p>\n Distro packages make this messier, because Debian and Ubuntu and RHEL-family vendors backport security fixes without bumping the upstream version. Rapid7 notes this too: its authenticated Linux package checks recognize backported fixes that keep the original version number. If you’re on a distro package, the build date in I should flag that this is my own check, and it assumes your vendor names the CVE in the changelog, which most do but not all. No match doesn’t prove you’re vulnerable, and a match tells you the package claims a fix. Treat a missing line as a prompt to read your distro’s security tracker.<\/p>\n If you’re on 8.1, 8.0 or 7.4 from a distro or hosting provider that is still maintaining it: check the changelog as above, patch, restart the workers, and verify. Then put the real upgrade on the calendar, because the vendor will drop it eventually.<\/p>\n If you’re on 8.1, 8.0 or 7.4 and building from source or using a plain Docker tag: you’ll need the project’s source backports or a newer tag. A Docker image tagged If you’re on 7.3 or older: there’s no patch. Huntress, in its rapid response write-up<\/a>, suggests taking end-of-life PHP off the internet, or putting it behind a VPN or WAF. It also suggests adding Inventory the bundled copies too. Huntress specifically advises finding PHP installed inside vendor software. A control panel, a CMS installer or an old billing tool can carry its own PHP binary that your system Patching a backport buys time, nothing more. The real answer to PHP 7.4 end of life, or PHP 8.1 end of life for that matter, is moving to a supported branch, and the sooner the smaller the jump.<\/p>\n My routine for a client app like the invoicing one is boring. I clone the production code into a branch, run it under the newest supported PHP in a container with the test suite and a static analyser, and read the list of deprecations it produces before I touch a line. Most of the pain is a few dozen deprecated calls and one or two libraries that need a major version bump. The first run is always uglier than the second.<\/p>\n I do it in steps, not one leap. I’d rather ship 7.4 to 8.1 this month with the new build date confirmed, then 8.1 to 8.3 next quarter, than hold a six-month branch open that nobody wants to merge. While the app stays on the old branch, I keep it off the public internet where I can, or behind the proxy request limits I set up in my VPS hardening notes<\/a>.<\/p>\n “It works” is a statement about yesterday. For the 7.4 app, I can now say three concrete things.<\/p>\n The branch has had no routine upstream updates for a long time. A critical unauthenticated bug just landed that it can only get through a special backport. And the cheapest realistic option for 7.3 and older is paid support.<\/p>\n I’d also point at the cost side: the longer a branch sits unsupported, the bigger the jump becomes. I wrote about planning those windows in my Laravel 13 support window post<\/a>, and the same logic applies to plain PHP. A jump from 7.4 to 8.3 breaks more than 8.1 to 8.3 does.<\/p>\nphp -v<\/code> cannot tell you if you’re safe. If you run 7.3 or older, no fix exists at all. The rest of this post is how to check, what to do about each case, and why I think “it works” has expired as an argument.<\/p>\nWhich branches got what<\/h2>\n
Why the version number lies<\/h2>\n
# example output\n$ php -v\nPHP 8.1.34 (cli) (built: Oct 21 2026 08:12:41) NTS\n<\/code><\/pre>\nphp -v<\/code> may not be a reliable signal. What I’d check instead is whether the vendor’s package changelog mentions the CVE:<\/p>\n# Debian \/ Ubuntu\napt changelog php8.1-cli 2>\/dev\/null | grep -m3 -E 'CVE-2026-109618|CVE-2026-109619'\n\n# RHEL \/ Alma \/ Rocky\nrpm -q --changelog php-fpm | grep -m3 -E 'CVE-2026-109618|CVE-2026-109619'\n<\/code><\/pre>\nWhat I’d do for each situation<\/h2>\n
php:8.1-fpm<\/code> that was last pulled before the 21st may still be sitting on a pre-fix build, and an old cached layer on your server is easy to forget. Pull again and read the build line instead of trusting the tag.<\/p>\nsession.upload_progress.enabled = Off<\/code> to php.ini<\/code> and restarting, which it says mitigates the known abuse cases. That’s a partial measure for one attack path, not a fix.<\/p>\nphp -v<\/code> never reveals. Plesk is a good example: its UI component needs a separate update (Obsidian 18.0.80 Update 11 or 18.0.81 Update 4) on top of the PHP builds.<\/p>\nA realistic route off the old branch<\/h2>\n
The argument I’d make to my client<\/h2>\n