PHP "PHP2shell" CVE-2026-109618: out-of-memory handling corrupts request data and may let unauthenticated attackers run code remotely

Who is affected

PHP is the server-side programming language behind a great many websites. Two flaws were patched together and nicknamed “PHP2shell”. This page covers CVE-2026-109618 (PHP’s title is “RCE via OOM corruption”, GitHub advisory GHSA-w8hw-w9fx-j79w); the other one is CVE-2026-109619.

Sources disagree on older versions:

• Datadog says PHP 5 through 8.1 are also vulnerable but are end of life and won’t be patched. Sansec says the vulnerable code dates back to PHP 5.4.0 (2012); PHP has not confirmed this.
• The maintainers’ GHSA lists affected versions as ”< 8.2.35, < 8.3.36, < 8.4.27, < 8.5.12”, with no lower bound; the NVD CPE’s first range likewise has only versionEndExcluding 8.2.35 and no start version, which literally includes 8.1 and earlier.
• The same vendor’s CVE record (CNA) lists only 8.2.–8.5. ranges and marks everything else “unaffected” by default (defaultStatus). This page lists both without picking one; detection and fix advice cover the union, so treat 8.1 and earlier as possibly affected. watchTowr also notes the “PHP 5 onward” scope has not been confirmed by an official advisory.
• Our analysis: PHP chose to publish backports for 7.4, 8.0 and 8.1, which suggests those branches are affected, but PHP does not say so.

Attack conditions (confirmed by PHP): the attack works over HTTP; PHP says it needs no authentication. It has been demonstrated against Apache mod_php (PHP loaded directly into Apache), where it runs entirely before any application code executes (per the GHSA, FrankenPHP is likely the same). FPM (a separate pool of PHP processes) exits the child when request startup fails; source analysis still suggests it is susceptible, but the trigger happens after normal startup, in application-specific scenarios, and no complete FPM exploit has been shown. Per the GHSA, LSAPI resembles FPM. php.net lists FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed as at risk, and considers mod_php highest.

Researchers add: Datadog says application-level login cannot block the attack (PHP confirms the pre-application path only on mod_php) and that any PHP script exposes the vulnerable path; Sansec says every known trigger is a multipart/form-data (form upload) request.

Sources disagree on whether session upload progress matters: JFrog (that page contains exploit material; we do not link it) lists session.upload_progress.enabled=On (the default) plus accepted multipart uploads as required; Datadog says turning that setting off does not protect you; PHP lists that measure only under CVE-2026-109619.

How it works

When PHP handles a web request, it first builds internal data for that request in memory. If it runs out of memory (OOM) part-way through, PHP uses longjmp() (a C mechanism that jumps straight out of the current flow) to abandon the request.

The trouble is that some code paths don’t account for being jumped out of during an allocation, and leave request data uninitialized beforehand. The request cleanup then treats that invalid data as valid, which corrupts memory. The CVE record’s weakness types include CWE-416 (use after free), CWE-824 (access of uninitialized pointer), CWE-755 (improper handling of exceptional conditions), CWE-1325 and CWE-1419. It says several OOM strategies can trigger this consistently and lead to remote code execution. PHP adds that even with memory_limit=-1, a real underlying allocation failure can still reach the vulnerable code.

The flawed approach (conceptual illustration, not PHP source code):

req->data = /* not set yet */;
buf = allocate(size);   // out of memory → jump out; req->data is never set
req->data = buf;
...
cleanup(req);           // treats req->data as valid → memory corruption

A safer approach (conceptual illustration):

req->data = NULL;       // set a safe empty value before any allocation that can fail
buf = allocate(size);
req->data = buf;
...
cleanup(req);           // recognises the empty value and doesn't misuse it

The fix mechanism: per the maintainers’ GHSA, the patch removes longjmp() for OOM and replaces it with a delayed, graceful soft OOM triggered at the next VM safe point, plus an immediate hard OOM using _exit() if memory use passes a higher threshold. The commit number 31c0ea7d7ff comes from JFrog (that page contains exploit material; we do not link it). The two snippets above are conceptual only and do not represent PHP’s official fix.

Sources disagree on the root cause: Sansec classifies CVE-2026-109618 as an upload-progress unserializer use-after-free, and JFrog says it stores request-owned pointers in persistent variables. PHP’s own description of this CVE is about half-initialized data during OOM handling; in PHP’s wording, upload progress and stale global state belong closer to CVE-2026-109619. This page follows PHP’s description.

Impact: the maintainers’ GHSA says the confirmed impact is unauthenticated remote code execution as the web worker account. Sansec also says this flaw can leak memory on its own (Heartbleed-style); PHP has not confirmed this.

Timeline

Further reading

• Scoring differences: The page’s main severity field uses NVD’s CVSS 3.1 score of 9.8 (AV:N/AC:L/PR:N/UI:N), with “low” attack complexity. Reason: NVD is the scoring authority for CVSS 3.1, and 3.1 is the most widely used version, which makes comparison with other flaws easier. PHP’s (CNA) CVSS 4.0 score is 9.2 (AC:H/AT:P), with “high” complexity and attack requirements present; it is equally valid, so read both. SANS ISC (that page contains exploit material; we do not link it) cited 9.4, which differs from PHP’s 9.2.
• Sources disagree on exploitation: watchTowr says its honeypots saw exploitation on October 21 (the same page still has outdated text saying no fix exists); Aikido says exploitation has been reported but doesn’t say for which CVE; before release, SecurityWeek reported that watchTowr and Huntress had seen none; CISA’s SSVC enrichment (2026-10-21 14:34 UTC) rates exploitation “none”. As of 2026-10-21 it is not in CISA KEV.
• Public proof-of-concept: SANS ISC (that page contains exploit material; we do not link it) says proof-of-concept (PoC) exploits and technical details are public, but the early PoC it reviewed does not appear reliable. We do not link any exploit material.
• Credits: per Sansec, both bugs were found by Ryan Austin of Calif, Wiz Research (Sagi Tzadik, Shir Tamari, Nir Ohfeld, Tomer Schwartz) and OpenAI.
• Related flaw: CVE-2026-109619 (same release). Related weakness types include: CWE-416, CWE-824, CWE-755, CWE-1325, CWE-1419.