php2shell: Critical PHP RCE (CVE-2026-109618 & CVE-2026-109619)

TLDR

• php2shell (CVE-2026-109618 and CVE-2026-109619) is a pair of critical, unauthenticated remote code execution flaws in PHP. They affect all versions of PHP from 5.4 through 8.5 and supported versions were patched on 21 October 2026.
• Update PHP now. Patching to a fixed release is the only reliable fix, mitigations do not fully work. If you run PHP anywhere internet-facing, treat this as urgent.
• Consider Products Using PHP. PHP is everywhere, so make sure to consider products you may use like WordPress, Magento, MediaWiki and Drupal. Also consider frameworks you may use for PHP development such as Laravel, CodeIgniter, and Symfony

What is php2shell?

On 21 October 2026, the PHP project released fixes for two critical vulnerabilities nicknamed php2shell, discovered and reported by the researchers at Calif.io. The two issues are closely related but distinct:

• CVE-2026-109618 — RCE via OOM corruption. PHP uses a jump to abort a request when it runs out of memory. If that abort fires while request data is only partially initialised — for example, while parsing a large multipart upload — the request is left in an invalid state that request shutdown then treats as valid. The result is an unauthenticated use-after-free.
• CVE-2026-109619 — RCE via stale global state. Request-owned state (including session and object data) can survive after the memory backing it has been freed. A later request handled by the same worker can then use that stale state before normal initialisation resets it.

Either path can lead to remote code execution with the privileges of the web worker from an unauthenticated perspective. The session upload-progress and object-deserialization code paths are the practical routes an attacker uses to reach the bug.

The root cause has a long history - back in 2004, Stefan Esser described almost exactly this class of problem in a bugtraq advisory: triggering PHP's memory-limit termination "in places where an interruption is unsafe." Twenty-two years later, the same unsafe-interruption pattern is back as a critical RCE.

This incredible bug affects millions of systems exposed to the internet, and is arguably the biggest impact vulnerability to be found in the past few years at least. The research team that found these bugs explained that once they were onto the right track, it took only a few days of asking the right questions to lead to the first breakthrough. AI-assisted vulnerability research is very much the new normal, and when performed by top researchers it has proven time and again it can uncover highly critical bugs in hardened targets that have been picked over for years. wp2shell was another recent example of this.

What's affected?

The vulnerable code reaches back as far as PHP 5.4. Fixed releases are:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Everything on the 8.2–8.5 branches below those versions is affected, as are all end-of-life branches (5.4 through 8.1), which receive no official fix. Products making use of PHP are also affected, so look out for patches in those products and get those in place ASAP.

A large amount of the internet still runs unsupported PHP - which is unfortunate because it means they have little recourse except to bring their systems offline and upgrade or wait for backports. Whilst the project has signalled it will not backport a patch, the community is already stepping in to plug gaps — see the effort shared here. This is only one example however, and there will be plenty of products and distros which will not get a patch for some time, or at all.

AI slop

As is now common with high-profile bugs, disinformation and false PoCs were everywhere post-disclosure. In a race to be first, many false PoCs and AI-generated attempts which were incorrect were shared publicly, in amongst real information from researchers who knew what they were doing. Many had the right idea, but in practice their code didn't work against real PHP builds.

LLMs now let almost anyone attempt to reverse-engineer a vulnerability and generate plausible-looking exploit code in minutes. It's an incredibly powerful tool, but complex bugs still need a smart human to drive them, ask the right questions, and correct mistakes. This is causing massive problems for bug bounty programs and product vendors, because they receive a massive influx or correct-looking PoCs, and they have to sift through this sea of slop to find the gems that are from well-informed researchers. The reality is that the good researchers are also using AI, and therefore their good reports can look exactly the same as the bad ones, and get lost. It's tough out there.

What do I need to do about php2shell?

Patch. Upgrade PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, and consider taking systems offline which cannot be upgraded yet. If you are on an end-of-life version (5.4–8.1), check for backport availability, and plan a migration to a supported release ASAP.

PHP's advisory notes some interim measures that reduce exposure but they warn that these should not be relied upon: setting memory_limit=-1, disabling session.upload_progress, and tightening post_max_size.

Intruder has produced an active check for CVE-2026-109618 which checks for systems which show an OOM condition consistent with unpatched systems. This check can be used to confirm whether the patch has been successfully deployed or not, and identify systems that were missed.

Additional reading and research

• Calif.io — php2shell research (original discovery)
• GitHub Security Advisory — CVE-2026-109618 (OOM corruption)
• GitHub Security Advisory — CVE-2026-109619 (stale global state)
• PHP.net — October 2026 security releases
• Stefan Esser, bugtraq (2004) — PHP memory_limit remote vulnerability

Changelog

• 22 October 2026 — Initial post.