PHP2Shell (CVE-2026-109618 and CVE-2026-109619) Explained: Two Different Bugs, the Invariants the Patch Restores, and What Operators Should Check Today

On 21 October 2026 the PHP project released fixes for two critical vulnerabilities that can lead to unauthenticated remote code execution (RCE). The researchers who found them nicknamed the pair "PHP2Shell". Because so much of the web runs on PHP, the potential reach is large.

This article answers three questions:

• Is my service affected, and what should I check first?
• How do the two vulnerabilities differ, and why can they allow code to run remotely?
• Which program rule that was being broken did the fix restore?

Scope. No attack code or procedure is included — only what the official advisories and the fix commit let you understand about the mechanism, plus defenses. The C examples are independent teaching code for the same class of bug and are not a reproduction of PHP2Shell. Information reflects primary sources as of 1 November 2026 (JST).

Key points in 30 seconds

• There are two vulnerabilities, and they are different. CVE-2026-109618 (out-of-memory handling corrupts internal state) and CVE-2026-109619 (stale state from a previous request survives).
• Fixed versions: PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 (released 21 October 2026). PHP 8.1 and older are outside the PHP project's updates.
• They are being exploited: CISA added both to its Known Exploited Vulnerabilities catalog on 26 October.
• Highest-risk runtime: Apache mod_php, where an attack has been demonstrated to succeed right after a request is accepted, before any application code runs.
• Configuration mitigations are incomplete. The vendor states plainly that updating is the only complete fix.
• Check: the PHP version your web server runs (not the CLI), whether your OS vendor has taken the fix, any end-of-life version, and signs of compromise.

Facts confirmed in official sources

Three notes on reading these:

1. The scores are CVSS v4.0. In the GHSAs the author checked, no v3.x score is attached. If you see a v3.1 score elsewhere, check the source and who scored it.
2. "High attack complexity" (AC:H) does not mean "safe". It reflects a dependence on memory layout; demonstrations and observed exploitation both exist.
3. How it was found: according to the researchers' write-up, a memory-limit issue was reported in 2020 and rediscovered in a 2024 external audit, but it was not fixed because exploitation had not been shown. It illustrates how hard it is to decide on "fix only once exploitability is proven".

Status by runtime (SAPI): separate "demonstrated" from "can be affected"

The most important thing in reading the two CVEs is how the situation differs by runtime. The GHSAs' statements, as a table:

The PHP project says the exposed population is "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed", and rates mod_php as highest risk.

Background: how PHP handles a request

A hotel housekeeper

A PHP worker (the process that handles requests) is like a hotel housekeeper.

1. A guest arrives (a request starts)
2. The housekeeper prepares a room for that guest (allocates memory for that request)
3. The guest's needs are handled (PHP code runs)
4. When the guest leaves, the room is cleaned and reset for the next guest (request shutdown)

The key point: one housekeeper serves many guests in turn. The housekeeper keeps notes (global state) that survive from one guest to the next. If a note still says "the key to room 3 is here" after room 3 has been demolished, the next guest arrives and the housekeeper acts on a key to a room that no longer exists.

The two PHP2Shell vulnerabilities are two different forms of this "cleanup failure":

• 109619: after a guest leaves, a note still points at the demolished room and gets used before the next guest is prepared
• 109618: an emergency stop hits partway through preparing a room, and the cleaner then works as if "everything is in place" in a half-furnished room

Terms

• Zend Engine: the core of PHP. It interprets PHP code and also manages memory.
• Request lifecycle: start-up → execution → shutdown.
• OOM (out of memory): in PHP this happens when memory_limit (default 128M) is exceeded.
• longjmp: a C mechanism that jumps straight from where you are to a designated point far away. The rest of every function in between is not run. PHP used it to abort processing on errors.
• Use after free: reading or writing freed memory as if still valid. If an attacker can influence what the memory was reused for, the program's behavior can potentially be taken over.

Why longjmp differs from normal control flow

Normally, when a function finishes, it runs its cleanup code (for example "release the memory I allocated", "restore the state") before returning to its caller.

function A → function B → function C
         ↑ C finishes → B cleans up → A cleans up   (normal)

function A → function B → function C ── longjmp ──▶ a safe point outside A
                          (the cleanup of B and C is skipped entirely)

A longjmp skips the cleanup of every function it jumps over, so the program's internal state is left mid-way. If something reads that mid-way state later, there is a problem.

The invariants that were broken

An "invariant" is a rule that should hold at every point in the program. For example: "in a linked list, every element's buf is either allocated or NULL".

• The rule 109618 broke: "whenever request memory becomes reachable (to cleanup code), its contents are fully initialized"
• The rule 109619 broke: "when a request ends, every global that points into that request's memory has been reset"

For 109618 the GHSA says request memory is temporarily reachable before it is fully initialized; if an allocation fails then, the early exit is not accounted for and invalid state is left behind.

Reading the patch: what changed and how

The PHP fix is in the php-src commit 506e87fa7dcd "Avoid state corruption via bailout" (18 October 2026, PHP-8.4 branch). Its message has two lines:

• Replace bailout on OOM with UnwindExit
• Properly reset various globals that may be accessed during startup

On the PHP-8.4 branch the commit changes over 300 files (GitHub's comparison view caps at 300, so the author did not confirm the exact count). The parts the author actually read are the diff statistics, the allocator core (Zend/zend_alloc.c) and the session extension (ext/session/session.c). Most of the change is tests that deliberately trigger out-of-memory.

Fix 1: do not longjmp on out-of-memory (Zend/zend_alloc.c)

Before the fix, exceeding the memory limit called zend_mm_safe_error(), which raised an error and called zend_bailout() (an exit via longjmp).

After the fix:

The point is that "jump right here" became "record it, and stop at a safe point". If memory use runs away past the hard limit, the process ends with no cleanup at all — a deliberately blunt last resort to keep broken state from being read by anyone.

A new setting, memory_hard_limit_percent, was added as well. As far as the author read, the default is unset (-1), in which case the limit is about 200% of memory_limit, or memory_limit + 1 GB when memory_limit exceeds 1 GB. Values below 100 (other than -1) are rejected with a warning.

Operational impact (author's reading): on reaching the hard limit PHP does not show a normal error page — the process exits immediately (status 137). With FPM a child dies and the master restarts it; with mod_php an Apache child dies. After updating, add monitoring for "Hard memory limit" in logs and for an increase in abnormal worker exits.

Fix 2: always reset request-owned state (ext/session/session.c and others)

In the session extension's diff you can see:

• PS(in_rfc1867_update) = false; added to per-request initialization (php_rinit_session_globals)
• A stale TODO removed: "These should be initialized by php_rshutdown_session_globals() always when execution is finished"
• The upload-progress handler (which runs during request startup, before normal initialization) now keeps objects as incomplete classes, so no user code can run

So what was fixed is that even if cleanup is skipped, the next request's initialization does not trust stale state. The commit message's "Properly reset various globals that may be accessed during startup" refers to this.

The invariants the fix protects

Why happy-path tests are not enough

Bugs like this live in code that runs only on error paths (out of memory, fatal errors). Ordinary tests assume memory is available, so they never reach these paths.

The commit adds a large number of out-of-memory tests, such as Zend/tests/oom_*.phpt. A code comment explains that ZEND_MM_MAX_ALLOCS fails the n-th allocation of a request, so the OOM handling can be exercised at any allocation, not only at allocations big enough to hit the limit.

This idea carries over to ordinary applications: a test that fails the n-th call (fault injection) exercises error paths that are normally never run.

A safe teaching example: watching memory lifetimes with AddressSanitizer

Here is the same class of bug in small C programs. To repeat: it is not PHP code and not a reproduction of PHP2Shell. It just lines up three ingredients — per-request memory, a global reference to it, and longjmp — in simplified form. Run it in an isolated environment of your own.

Example 1: a global reference outlives the freed region (the 109619 class)

/* Teaching code: per-request memory and a global pointer into it */
#include <setjmp.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static jmp_buf bailout;
static char *arena;        /* per-request memory */
static char *cached_name;  /* a global that outlives the request */

static void *req_alloc(size_t n, size_t limit) {
  if (n > limit) longjmp(bailout, 1);   /* "memory limit exceeded": jump out */
  return arena;
}

static void handle(const char *input, size_t limit) {
  cached_name = req_alloc(16, limit);
  strcpy(cached_name, "session-A");
  req_alloc(strlen(input) * 1000, limit);   /* may jump out here */
  cached_name = NULL;                       /* runs only on success */
}

static void request(const char *input, size_t limit) {
  arena = malloc(64);
#ifdef FIXED
  if (setjmp(bailout) == 0) handle(input, limit);
  cached_name = NULL;                       /* fix: reset at the boundary, on every path */
#else
  if (setjmp(bailout) == 0) handle(input, limit);
#endif
  free(arena);                              /* request end: release the region */
}

int main(void) {
  request("x", 1u << 20);                   /* a normal request */
  request("a-very-long-input", 64);         /* failure path: jumps out midway */
  if (cached_name) printf("next sees: %s\n", cached_name);   /* reads freed memory */
  else puts("next sees: (cleared)");
  return 0;
}

clang -g -O0 -fsanitize=address lifetime.c -o bug
clang -g -O0 -fsanitize=address -DFIXED lifetime.c -o fixed
./bug     # aborts, reporting a read of freed memory
./fixed   # exits normally

Result of the author's run (Apple clang 21.0.0, -fsanitize=address):

• Before the fix: AddressSanitizer: heap-use-after-free, with stack traces for where it was freed (free(arena) in request) and where it was allocated
• After the fix (-DFIXED): prints next sees: (cleared) and exits with nothing detected

What to take from it:

• The cause is that the reset exists only on the success path — cached_name = NULL; is not run once longjmp jumps out
• The fix is to reset at a boundary every path goes through (this mirrors PHP's fix 3)

Example 2: jumping out mid-initialization, then cleanup reads broken state (the 109618 class)

/* Teaching code: add to a list, then jump out before initializing the contents */
struct node { struct node *next; char *buf; };
static struct node *head;      /* the list walked at request end */

static void add_header(size_t len) {
  struct node *n = malloc(sizeof *n);    /* contents uninitialized */
  n->next = head; head = n;              /* published to the list too early */
  n->buf = req_alloc(len);               /* may jump out here */
}

static void shutdown_request(void) {     /* always runs */
  for (struct node *n = head, *next; n; n = next) {
    next = n->next;
    free(n->buf);                        /* trusts that buf is valid or NULL */
    free(n);
  }
}

Example 2 is an excerpt. req_alloc here is assumed to be a one-argument version of example 1's function, without the limit parameter. The -DFIXED variant and main are omitted, so this excerpt alone cannot reproduce the results below.

The fixed version (-DFIXED) records an allocation failure instead of jumping out on the spot, and handles it at the next safe point (the same idea as PHP's fix 1).

Result of the author's run:

• Before the fix: ASan reports SEGV on unknown address (in shutdown_request, at the free(n->buf) line)
• After the fix: prints "OOM handled at a safe point" and "shutdown completed", then exits normally

This shows another principle: finish initializing before you publish (for example, fill in the fields before putting the node on the list).

Limits of the teaching code

• It is a conceptual model. It does not reproduce PHP's allocator (zend_mm) or the conditions an actual exploit needs
• Behavior changes with optimization, OS and allocator (the ASan results are observations in the author's environment)
• Making arbitrary code run is deliberately not reproduced here, and should not be

For operators: checking whether you are affected

Step 1: Identify the PHP your web server runs

php -v on the CLI and the PHP serving the web can differ (several versions side by side, containers, per-pool FPM versions).

# CLI version (may differ from the web)
php -v

# FPM version and running processes
php-fpm -v 2>/dev/null; ps aux | grep -E 'php-fpm|php-cgi|frankenphp|lsphp' | grep -v grep

# Is mod_php loaded into Apache?
apachectl -M 2>/dev/null | grep -i php

To know the version the web really runs, execute PHP on that server and print the version. Do it by an administrator-only means, and never publish a page that leaks version information.

Step 2: Check OS-vendor backports

On Debian, Ubuntu, RHEL and similar, a fix can be folded in without the version number rising. Don't conclude "unpatched" from the number alone.

# Debian/Ubuntu: does the changelog name the CVE?
apt changelog php8.3-fpm 2>/dev/null | grep -E 'CVE-2026-10961[89]'

# RHEL family
rpm -q --changelog php-fpm 2>/dev/null | grep -E 'CVE-2026-10961[89]'

If nothing turns up, check your distribution's official security tracker for whether your version is fixed.

Step 3: Look for end-of-life versions

• PHP 8.1 and older are outside the PHP project's updates. Upgrade, or use a vendor LTS with backports
• Given the severity, the PHP project provided minimal source backports for PHP 7.4, 8.0 and 8.1 (a stopgap if you build from source or have no LTS source)
• Cisco Talos notes that PHP 8.2 security support ends on 31 December 2026. Use this as the occasion to plan a move to 8.3 or later

Step 4: Interim mitigations if you cannot update yet, and their limits

Updating comes first; the following only buys time. The vendor too says they reduce exposure to specific paths and do not make an installation safe.

Verify a setting against what the web workers actually read:

# CLI settings (may differ from the web workers)
php -i | grep -E 'session.upload_progress.enabled|memory_limit|fatal_error_backtraces'

# php.ini values FPM actually loads (closest to the web workers)
php-fpm -i | grep -E 'session.upload_progress.enabled|memory_limit|fatal_error_backtraces'

# Per-pool overrides (php_value / php_admin_value). php.ini values do not appear in -tt
php-fpm -tt 2>&1 | grep -E 'php_(admin_)?(value|flag)'

Step 5: Look for signs of compromise

JPCERT/CC, citing the discoverers, lists the following to check. No single detection rule is guaranteed to catch every attack.

• Past HTTP responses that set a PHPSESSID cookie with an unnaturally long or malformed value
• Suspicious multipart/form-data requests, and PHP memory-limit errors or HTTP 500s around them
• PHP workers exiting unexpectedly or restarting frequently

The absence of a trace in logs is not proof of safety; the vendor likewise says log audits only cover the paths that were exercised.

In its 29 October update JPCERT/CC conveys reports that, in an investigation of attack activity, traces suggesting successful compromise of a specific version of a firewall product were found; that the attacker appears to have combined the PHP vulnerability with a Linux kernel privilege-escalation vulnerability; and that attempts at lateral movement into internal networks are suggested. Appliances and products that embed PHP, not only websites, are in scope.

For executives: what to decide, in what order

For non-engineers, the order of decisions:

1. Today: list every server and service that runs PHP (ask staff or contractors). The less the IT department knows about something — an old admin screen, a contractor-built site, an appliance's embedded web UI — the more dangerous it is.
2. This week: set update priorities. Start with what is internet-facing, on an old PHP version and handling customer data. Anything run via mod_php comes first.
3. At the same time: get written confirmation of patch status from contractors and hosting providers. On shared hosting you depend on the provider.
4. After: investigate for compromise together with the update. The update closes the hole, but an intruder who is already in stays in.
5. Medium term: put the migration off PHP 8.1 and older, and off 8.2 as its support ends, in the budget.

"We only run WordPress, so we're fine" does not hold: if the PHP runtime is unpatched, you can be affected even when WordPress itself has no vulnerability.

Frameworks: Laravel and WordPress

Because 109619 notes that fatal errors can be part of the path, fatal errors caused by plugins or extensions (for example in upload, import, error-page or shutdown handling) also matter, so reducing the fatal errors an attacker can reach remains a useful layer of defense after updating.

How CVE-2026-115560 relates

• It is a separate vulnerability, disclosed by php.net on 23 October as an informational advisory
• It applies only in an unusual combination: session.serialize_handler configured as php_binary or php_serialize, the app switching to php with ini_set() at run time and calling session_start(), with session upload progress enabled
• php.net calls this setup unlikely in practice, will fix it in the regular release cycle, and promises a full advisory with the next release
• When the author checked on 31 October 2026, no CVE record was public at cve.org or NVD (a "does not exist" response)
• Whether this release (8.2.35 and the others) fixes it is not stated as "fixed" in the vendor's text. The vendor's interim mitigation is session.upload_progress.enabled=0

Do not treat the two PHP2Shell CVEs and 115560 as "the same vulnerability". Nor can you say they are "unrelated": both involve session upload progress. Until a new advisory appears, keep the configuration mitigation in place.

The author's view: what to learn from this

The following is the author's reading of the published facts.

1. "Fix only once exploitability is proven" is a dangerous criterion. The researchers say an issue reported in 2020 and flagged in 2024 stayed unfixed until exploitation was shown. Corruption of state on error paths can look harmless alone and become severe in combination with other bugs.
2. Happy-path tests do not find this kind of bug. What the fix added were tests that inject failure. In your own code, tests that "fail the n-th external call" or "fail a memory allocation" run the cleanup paths that normally never execute.
3. The speed of updating decides the size of the damage. With exploitation observed, "wait and see" is not an option. Practising updates in peacetime determines the loss on days like this.
4. PHP versions typically differ from server to server. Organizations without a complete asset inventory are the ones who miss things.

Conclusion and what to watch next

• What can be said as fact: two separate CVEs were fixed in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Both are on KEV and exploitation has been observed. The demonstrated RCE is mainly on mod_php, with conditional paths validated on FPM.
• What cannot yet be said: whether attacks succeed on every runtime, and the real scale of damage. Whether a complete attack on 109618 is possible on FPM. The details of CVE-2026-115560.
• To watch: the 115560 advisory and CVE, the next PHP release, distribution backport status, and updates from JPCERT/CC and IPA.

If you want a vulnerability assessment or code audit of your own service

The author assesses the security of web applications and cloud environments from production experience with Next.js, Python, Go and AWS. Updating PHP closes these holes, but problems left in the application itself — authorization flaws, misconfiguration, secret handling — need separate review.

What I can and cannot do, up front:

• I can: perform source-and-configuration-based web application vulnerability assessments and code audits, with a prioritized fix plan and re-verification after fixes
• I cannot: perform forensic investigation after a compromise, or discover vulnerabilities inside PHP itself. If you suspect compromise, contact a specialist incident-response firm first
• I cannot promise you will be "completely secure". I report what was found and what was not examined, as it is

See the scope and pricing through the button below.