php2shell Explained: What to Patch Today, and What to Replace This Year

On 21 October 2026 the PHP project disclosed two vulnerabilities in the language runtime itself, nicknamed php2shell. CVE-2026-109618 and CVE-2026-109619 both carry a CVSS v4.0 base score of 9.2, and both can lead to unauthenticated remote code execution. They are fixed in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, released the same day.

This is not a WordPress bug or a Magento bug. It is a bug in the engine underneath them, which is why Sansec was able to confirm unauthenticated remote code execution against Magento 2.4.9, WordPress, Drupal, Joomla, Laravel, Symfony and several other applications whose own code is perfectly clean. PHP runs 69.3% of websites whose server-side language is known, so the blast radius is most of the web.

The PHP security team's own guidance is unusually blunt: there are no complete mitigations, and updating is the only safe choice.

What php2shell actually is

Two separate flaws that happen to combine well.

CVE-2026-109618 is memory corruption during out-of-memory handling. PHP exits a request on OOM using longjmp(), and in some contexts request memory is reachable before it has been fully initialized. The early jump leaves that memory invalid, and request shutdown then reads or branches on it.

The part that makes this reachable from the internet is how the out-of-memory condition gets triggered. It is not a huge request body. It is a cheap body that is expensive to parse: a multipart request with no usable declared content length passes the initial post_max_size check, parts can carry headers that expand substantially in memory, and empty file controls do not count toward max_file_uploads while still allocating file-metadata arrays. Multipart parsing happens before module initialization, which is precisely why application-level hardening does not help.

CVE-2026-109619 is a cross-request use-after-free. Request-owned global state can survive after its backing memory has been freed, and a later request handled by the same worker may use that stale state before normal initialization resets it. Exploitation needs a producer, which stores state that persists through a fatal error, OOM or timeout, and a consumer that acts on it on a later request in the same worker. Session upload progress is a confirmed consumer, and it is enabled by default.

Wiz, who found and reported the flaws, also demonstrated a memory disclosure path that leaks freed memory into a PHPSESSID cookie, exposing passwords, tokens, API keys and certificates, and defeating address space layout randomization along the way.

Whether you are exposed, and why your version number cannot tell you

This is where most of the advice circulating this week is quietly wrong.

The obvious check is to look at your PHP version and compare it against the fixed list. That check produces false answers in both directions, because Linux distributions backport security fixes without changing the version number. A patched PHP 8.1.34 and an unpatched PHP 8.1.34 report exactly the same string. If you run php -v, see 8.1.34, and conclude you are vulnerable, you may be wrong. If you see it and conclude you are fine, you may also be wrong.

What actually answers the question is your vendor's package version and its changelog. On Ubuntu 22.04 the patched package is 8.1.2-1ubuntu2.28. On Debian bookworm it is 8.2.35-1~deb12u1. Those are the strings that mean something, not the number PHP prints.

What to do in the next 24 hours

1. Update to a patched branch and restart every worker. The fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Both producer and consumer in the second flaw have to land on the same worker process, so a restart matters as much as the package.
2. Check your distribution, not just PHP. The version you need may be a backport that carries an older-looking number.
3. Apply the administrative mitigations where you cannot patch immediately. Set memory_limit=-1 where applications cannot override it, set session.upload_progress.enabled=0, and on PHP 8.5 also set fatal_error_backtraces=0. These reduce exposure. They do not make an installation safe, and ini_set() and .user.ini are applied too late to help.
4. Put a WAF in front of it as a stopgap. Cloudflare shipped rules including on the free tier, and Google Cloud published guidance recommending its File Upload and RFI rule categories along with a rule for request bodies that exceed inspection limits. This protects traffic routed through the proxy and nothing else.

On exploitation, the honest position is narrower than the headlines. Amazon observed an exploitation attempt against its MadPot honeypot on 17 October, four days before disclosure, and details leaked publicly on 20 October, which moved the release forward by a day. But Recorded Future's Insikt Group states that the available evidence does not establish the extent of successful exploitation or confirmed compromises, and SANS ISC describes the circulating proof-of-concept code as incomplete and not reliable. Neither CVE appears in CISA's Known Exploited Vulnerabilities catalog as of 22 October 2026.

That is still a reason to patch today. It is not a reason to believe anyone who tells you a working public exploit is available, and unverified exploit code circulating this week should be treated as malware rather than as a testing tool.

The end-of-life trap

Here is the part that turns a patching exercise into a planning problem.

The PHP project is not releasing fixes for PHP 8.1 or earlier. For 7.4, 8.0 and 8.1 the security team published minimal source backports only: not releases, not renewed support, just patches you are expected to apply and compile yourself.

Distributions partially fill that gap, and the detail matters more than the headline.

So the real risk of running end-of-life PHP is not that no patch exists. Sometimes one does. The risk is that you no longer control whether it exists. You are depending on a paid support tier, or a distribution that may have dropped your release, or your own team's willingness to compile a source patch under time pressure, or a version string that cannot confirm what you have. Sources: Ubuntu and the Debian security tracker.

This is not a rare situation. Black Kite's scan of version-disclosing internet-facing PHP hosts found roughly 72.5% running end-of-life branches, with PHP 7.4 the single largest. W3Techs puts PHP 7 at 26.9% of PHP sites and PHP 5 at 7.7%, which is a third of everything running PHP.

Why PHP 8.2 is not a destination

Most teams reading this will patch to the nearest supported branch and move on. For a lot of them that means 8.2.35.

PHP 8.2 reaches end of life on 31 December 2026.

That is ten weeks from this article. A team that patches to 8.2 this week has not solved the problem, it has rented a solution until the new year, at which point it is back in exactly the position described above: depending on a backport someone else may or may not produce.

This is the argument for treating php2shell as a scheduling event rather than an incident. The patch is urgent and it is not a plan. The plan is knowing which branch you are on, what your actual upgrade path looks like, what breaks when you take it, and whether the application on top is worth upgrading in place or worth moving.

What that looks like in practice

The useful question is not "are we vulnerable", because the honest answer this week is usually "probably not any more, and we cannot prove it from the version string". The useful questions are narrower:

• Which PHP branch is each application actually running, per environment rather than per assumption?
• Is the fix on that host from the standard archive, a paid support tier, or nowhere?
• What is the upgrade path to a branch that is supported past 31 December 2026, and what breaks on the way?
• Which applications are worth upgrading in place, and which are old enough that the upgrade cost and the replatform cost have converged?

The last one is the only question with real money attached, and it is the one nobody asks during an incident. It is worth asking in the two weeks afterward, while the risk is still legible to everyone who signs off budgets.

If you want a second pair of eyes on it, that is the work we do. The honest version of this engagement is short: we read what is actually deployed, tell you where the fix came from, and give you an upgrade path with the breakages named. Anyone who quotes you a replatform before answering the first three questions is selling you the wrong thing.