php2shell: no upstream fix for PHP 8.1 and older

PHP's own advisory does not tell most legacy estates to patch. It tells them to call their vendor or build from source. The security advisory published on 21 October 2026 says plainly that PHP 8.1 and older no longer receive updates from the PHP project, and that the security team published only "minimal source-backports" for 7.4, 8.0 and 8.1 as a courtesy. So php2shell splits the PHP world in two: if you are on 8.2 or above you install a package today, and if you are on 8.1 or below you have an unauthenticated remote code execution bug and no package at all. This post covers who must act, what the fix actually is per version, and how to get off an unsupported PHP quickly without breaking the application while you do it.

What php2shell is, and who has to act today

php2shell is the name Wiz Research gave the exploit script it built from two PHP vulnerabilities, CVE-2026-109618 ("RCE via OOM corruption") and CVE-2026-109619 ("RCE via stale global state"). PHP describes both as allowing unauthenticated remote code execution. The pre-announcement posted a day earlier rated both at CVSS v4.0 9.2.

The exposure is unusually wide. PHP's advisory puts the risk on "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed", and singles out mod_php as highest risk, "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs". That last clause is the part worth re-reading. Your framework's authentication, your WAF's application rules, your careful input validation — none of it is in the path. If you serve PHP over HTTP on an affected version, you are in scope regardless of what your code does.

Wiz reports that "every PHP version released in the last decade is affected by at least one of these vulnerabilities, going back to version 5.4", and that the first bug was found on 19 August 2026 with AI assistance, then reported to the PHP security team on 24 August. We have not analysed either CVE ourselves and are not going to pretend otherwise; everything above is read off php.net and the Wiz write-up, as of 21 October 2026.

Your version decides whether this is a patch or a project

Here is the actual decision table, taken from the advisory and PHP's own lifecycle pages.

Your PHP version	Upstream status	What you do
8.5, 8.4, 8.3, 8.2	Fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35	Update now. Check your distro first — LTS vendors got the patches in advance.
8.1	End of life 31 December 2025. No upstream release. Minimal source backport branch only.	Vendor backport if you have one, otherwise build from source as a bridge, then migrate.
8.0	End of life 26 November 2023. Minimal source backport branch only.	As above. Treat the backport as a tourniquet.
7.4	End of life 28 November 2022. Minimal source backport branch only.	As above, and expect the migration itself to be the real work.
7.3 and older	Nothing. 7.3 went end of life on 6 December 2021.	Migrate. There is no bridge offered for you.

Two details matter here. First, the 8.x ChangeLog dates 8.5.12 and 8.4.27 to 22 October 2026 and records the fix as a single Core entry — "Avoid state corruption via bailout" — against both GitHub advisories. It does not list the CVE identifiers; the mapping from CVE to GHSA is on the advisory page itself. If you are grepping a changelog for a CVE number to prove you are patched, check the version number instead.

Second, the backports for 7.4, 8.0 and 8.1 are source branches on GitHub, not releases. There is no tarball, no distro package, no tested build. Someone on your team compiles PHP, links your extensions, and ships it. That is a real option for an afternoon, and it is not a maintenance posture. And if you are on 8.2 feeling comfortable: PHP's supported-versions page puts 8.2's security support end at 31 December 2026, which the 8.2.35 release announcement repeats. You are nine weeks from the same conversation. We wrote about the downstream version of this problem when Magento 2.4.6 went out of support alongside PHP 8.2.

The stop-gaps reduce exposure and do not fix anything

If you genuinely cannot move this week, PHP publishes mitigations, and it is unusually blunt about their limits: "while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe". The release announcements go further — "There are no complete mitigations, updating is the only safe choice."

The measures worth knowing about, without going near how either bug works:

• For CVE-2026-109618, the advisory recommends setting memory_limit=-1 in a place applications cannot override — php_admin_value in the FPM pool or Apache config — and checking that no pool, directory or application setting puts a finite limit back. It warns an underlying allocation failure can still reach the vulnerable path.
• Also for 109618: a low post_max_size (8M where you have no uploads, 32M where you do), with upload_max_filesize below it, plus request-size and nesting limits enforced at the web server or proxy — including for requests without a usable Content-Length.
• For CVE-2026-109619, session.upload_progress.enabled=0 with every worker restarted, applied via php.ini, an FPM pool or server config rather than ini_set(). On 8.5, also fatal_error_backtraces=0. The advisory says this "blocks the confirmed session paths but not other variants".
• A container or cgroup limit as an availability boundary, and explicitly not RLIMIT_AS or RLIMIT_DATA, which the advisory says can themselves cause the dangerous allocation failure.

Note what is missing from that list: a WAF signature. Nothing in the advisory suggests a request-filtering rule that reliably blocks this, and the mod_php path fires before application code. By all means ask your WAF vendor what they have shipped, and hold it to the standard PHP holds its own mitigations to — exposure reduction, not a fix. Buying another week is a legitimate goal. Mistaking a week for a resolution is how estates end up here in the first place.

What actually breaks when you leave PHP 7.4 or 8.0

The reason your 7.4 application is still on 7.4 is that nobody could predict what the jump would break. The PHP manual can, in part. The 8.0 backward incompatible changes page is the single best guide to the risk, and almost none of it is syntax:

• Error severity shifted upward across the board. Reading an undefined variable, property or array key moved from notice to warning. Writing to a property of a non-object, using an invalid type as an array key, and passing the wrong argument count to a built-in function all became Error exceptions. Arithmetic on an array or object now throws TypeError.
• Loose comparison changed. Non-strict comparisons between a number and a non-numeric string now cast the number to string, so 0 == "foo" is false where it was true. Any code branching on that is now taking the other branch, silently and correctly.
• Error handling defaults changed. error_reporting defaults to E_ALL, @ no longer silences fatal errors, assertion failures throw, and PDO's default error mode moved from silent to exceptions.
• Things were removed outright — create_function(), each(), __autoload(), case-insensitive constants, calling non-static methods statically, and curly-brace offset access among them.

Then 8.2 deprecated dynamic properties unless a class opts in with #[\AllowDynamicProperties], along with "${var}" interpolation, relative callables like "parent::method", and utf8_encode()/utf8_decode(). For a mature codebase built on magic properties and loose typing, that one deprecation can touch hundreds of files.

Read that list again and notice the pattern: most of these failures are behavioural, not fatal. The code compiles. The page returns 200. A comparison flips, a silent PDO failure becomes an exception, a warning that was being swallowed is now an uncaught Error on one unlucky code path. A smoke test will not find it. Nor will your type checker.

Characterization tests are the precondition, not the nice-to-have

This is why we insist on the same first step on every one of these engagements, and why it is not optional when the clock is a live RCE: capture what the system does now, before you change the runtime under it. That is what characterization tests on legacy code before refactoring are for. They are not tests of correct behaviour. They are tests of current behaviour, including the behaviour you think is wrong, and they are the only artefact that can tell you whether 8.4 changed your application or only changed your error log.

Prioritise by money and by blast radius: payment and billing paths, anything writing to the ledger, authentication and session handling, scheduled jobs, file and import processing, and every integration that signs or parses something. Pin the outputs — HTTP responses, database writes, generated files, emitted emails — and run them against both runtimes. This is also where AI-assisted refactoring across a large legacy codebase earns its place: generating that coverage over an undocumented estate is exactly the kind of high-volume, low-judgement work it does well, under review.

A staged route off an unsupported PHP

1. Today: inventory and triage. Every host, every SAPI, every PHP version, including the containers nobody owns and the one legacy admin box. You cannot patch what is not on the list, and the version is what decides the plan.
2. This week: close the gap you can close. Patch everything on 8.2+ to the fixed releases. For 7.4/8.0/8.1, take the vendor backport if your distro has one, apply the advisory's mitigations, and reduce exposure — take non-essential PHP endpoints off the public internet, and move mod_php to PHP-FPM behind a proxy where you can.
3. Weeks one to three: characterization coverage over the paths above, running green on your current version.
4. Then: one version step at a time, not 7.4 to 8.4 in a single commit. Each step is a deployable change with the test suite as the gate, which is also what makes the work reviewable and reversible.
5. Finally: decide what the target is. 8.4 has active support until 31 December 2026 and security support to 31 December 2028; 8.5 runs to 31 December 2029. Landing on 8.2 because it is the shortest hop buys you nine weeks.

Our standing here is delivery, not vulnerability research: legacy application modernization is a practice we run, and the pattern above is the one we use when a system has to keep running while it moves. The custom ERP we built for a large-scale industrial client is the shape of the end state — HR, CRM, inventory and finance unified across four departments in one browser-based platform, with no data silos after launch.

What to decide this week

The question in front of you is not whether to patch. It is which of two projects you are starting. If every host is on 8.2 or above, this is a change window and you are done by Friday. If anything is on 8.1 or below, the decision is whether you build from a source branch and schedule the migration properly, or run mitigated and exposed while you argue about budget. Pick the first. The deferral that got you to 7.4 in 2026 was free right up until it was not.