Upgrade PHP 8.1 to 8.4? The dates say 8.5

If you upgrade PHP 8.1 to 8.4 this quarter, you will land on a branch whose active support ends on 31 December 2026 — about two months away. It still gets security fixes until the end of 2028, so it is a defensible choice. But it is not the obvious one, and the branch most upgrade guides name is not the one PHP's own calendar points at.

The reason you are reading this at all is php2shell: two unauthenticated remote code execution bugs that give every PHP 8.1 estate a critical vulnerability and nothing to install. Here are the real dates, the backport situation, and what the work actually consists of.

Upgrade PHP 8.1 to 8.4 and you land in security-only

PHP's policy is simple and worth knowing before you compare branches. From php.net: each branch is "fully supported for two years from its initial stable release", then "supported for two additional years for critical security issues only", and "Once the four years of support are completed, the branch reaches its end of life".

So every branch has two dates, and most comparisons only quote one:

Branch	Active support until	Security support until
8.1	—	Ended 31 Dec 2025
8.2	31 Dec 2024 (passed)	31 Dec 2026
8.3	31 Dec 2025 (passed)	31 Dec 2027
8.4	31 Dec 2026	31 Dec 2028
8.5	31 Dec 2027	31 Dec 2029

Read that as a planning table and three things fall out. PHP 8.1 has been end-of-life since 31 December 2025, so it has been nearly ten months without fixes — php2shell is the consequence, not the cause. Patching to 8.2.35 puts you on a branch that stops receiving security fixes on 31 December 2026, roughly ten weeks from now: that is not an upgrade, it is a deferral with paperwork. And 8.4 is two months from active-support expiry, which means you would be migrating onto a branch already in its second half.

Target 8.5. It has active support until 31 December 2027 and security fixes to 31 December 2029 — fourteen more months of active support than 8.4 and a year more of total runway, for an upgrade that costs much the same once you are already leaving 8.1.

The honest counter-argument: 8.5 shipped on 20 November 2025, so extension and tooling support is younger, and a conservative estate with many third-party extensions may genuinely find 8.4 smoother. If that is your situation, choose 8.4 deliberately and write 31 December 2028 into the roadmap. What you should not do is choose 8.4 because it is the number in a tutorial.

What php2shell actually leaves you on 8.1

The PHP advisory of 21 October 2026 is explicit about scope: "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed", with risk highest for mod_php, "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs".

That last clause is why this forces a migration rather than a mitigation. Your framework's authentication, your input validation and your application-layer WAF rules are not in the request path.

Fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For anything older, the advisory says "PHP 8.1 and older no longer receive updates from the PHP project" and points to "minimal source-backports" for 7.4, 8.0 and 8.1 in named php-src branches. Tenable's table puts the practical position plainly: for 7.4 through 8.1 there is "No official release; minimal source backports from the PHP security team", and for 5.4 through 7.3, "End-of-life, no fix from the PHP project".

A source backport is not a patch you apply on a Tuesday. It means compiling PHP from source, in a branch that receives nothing else, and owning that build. The advisory's own suggestion is the more realistic one for most teams: "Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages." If your distro ships a patched 8.1, take it — as a bridge of weeks, not quarters, because nothing else will be fixed in that branch again.

We wrote about the split this creates in more detail when the advisory landed: there is no upstream fix for PHP 8.1 and older.

What the 8.1 to 8.5 jump actually costs

Skipping three branches sounds worse than it is, because the breaking changes are concentrated and well documented. The work is rarely the language.

• Deprecations become fatals. The big one across this range is implicit nullable parameter types and the long tail of dynamic property creation. These are mechanical and a static analyser finds them in an afternoon.
• Extensions, not code. This is where the estimate moves. Every compiled extension needs a build for the target version, and an unmaintained one three levels down is the thing that turns two weeks into six. Audit extensions before you promise a date.
• The framework floor. Your framework version may not support 8.5, which makes this two migrations stacked. Check that first, because it can change the target branch decision entirely.
• Behaviour, not errors. Date handling, string-to-number comparison and sorting stability have all shifted across these branches. These pass tests and fail in production, so they are the argument for a characterisation test pass before you start rather than after.

For sizing: of the things above, only the extension audit and the framework floor are genuinely unpredictable. Everything else is proportional to your test coverage, which is the real variable in any estimate of this kind of work.

The interim measures, and how long they hold

PHP offers mitigations and is unusually blunt about their limits. The advisory frames them as measures that "reduce exposure to specific attack paths but do not make an installation safe", and the 8.5.12 release note goes further: "There are no complete mitigations, updating is the only safe choice."

So treat anything below as a bridge measured in days. Sophos's advisory lists the interim set: set file_uploads = Off, reject multipart/form-data requests at the web server or WAF, put applications behind ZTNA or take them offline, and restart workers. Its own caveat is the important part — "This workaround is not a substitute for updating PHP" — and it notes that in-application RASP or WAF layers "may not prevent exploitation", which follows from the exploit running before application code does.

One warning on the multipart rule specifically: Datadog's reproduction of CVE-2026-109618 used an application/x-www-form-urlencoded request, not multipart. A filter built only on multipart may not cover the bug it was written for. We cover that disagreement separately.

On scale, the published estimates disagree and both are worth quoting rather than picking one: Tenable cites "over 1.3 million internet-exposed hosts" from Silas Cutler and "over 1.9 million" from Shodan via Henk Poley. Either way the population of unpatched end-of-life PHP is large enough that scanning is indiscriminate.

Do it once, not twice

The pattern worth avoiding is the one this incident will produce at scale: an emergency hop to the nearest patched version in October, then a second project in the new year when that version stops getting fixes. Two migrations, two test cycles, two deployment risks, for one piece of value.

The same logic applies on every runtime with a published calendar, and the calendars are unusually crowded right now — Node 20 reached end of life in April and its October security release skipped it entirely, for exactly the same reason PHP 8.1 got nothing this week. Platform dates are public years in advance; what makes them expensive is that the application, not the platform, is the problem.

What to do this week

Establish the running version and SAPI on every host, not the version in your documentation — php -v on the box and phpinfo() through the web server, because they can differ. Then take your distro's patched package if one exists for your branch, as a bridge.

Then commit to a target branch and put its security-support date in the ticket: 31 December 2029 for 8.5, 31 December 2028 for 8.4. Audit extensions and the framework floor before you commit to a timeline, in that order, because those are the two findings that can change the target.

If the estate is large enough that the inventory itself is the project — several applications, mixed SAPIs, a shared host or two nobody owns — that is the position we are usually brought into. Legacy modernisation work on PHP almost always starts with establishing what is actually running where, because an unpatched remote code execution bug converts a deferred upgrade into an unplanned one at the worst possible moment.