php2shell: the PHP RCE pair CVE-2026-109618 and CVE-2026-109619

Most remote code execution bugs live in an application. php2shell lives underneath them, in the code PHP runs to prepare a request before your application sees it. That is what made the October disclosure unusual: on a mod_php server, an attacker needs no account, no vulnerable plugin and no route of their own choosing. They need PHP to start parsing what they sent.

The two CVEs were meant to ship quietly. Both identifiers leaked on 20 October 2026, a day before the coordinated release, which PHP then published at 14:00 UTC on 21 October. CISA issued an alert the same day and added both bugs to its Known Exploited Vulnerabilities catalog five days later, giving federal agencies until 29 October to patch.

Who is affected

Every supported PHP branch before these releases:

How exposed a given server is depends on how PHP is attached to the web server. mod_php (PHP loaded inside Apache) is the confirmed path for both bugs. PHP-FPM is conditional: one confirmed route for the second bug runs through session.upload_progress, which is on by default, and the sources disagree about how far the first bug reaches on FPM. Until you have upgraded, plan as if FPM is exposed too.

How php2shell works

The name covers two separate memory-safety bugs that end in the same place: attacker-controlled data treated as live memory inside the PHP worker.

CVE-2026-109618: running out of memory at the wrong moment

When PHP runs out of memory, it does not unwind politely. It jumps straight out of whatever it was doing. If that happens while the request is still being assembled, the half-built request data is left behind, and the end-of-request cleanup later operates on it as if it were whole.

The attacker's job is to force that out-of-memory condition without tripping the limits meant to prevent it. The advisory describes the quirks that make it possible in multipart form handling: requests with no usable Content-Length, an unlimited number of headers per part, empty file fields and deeply nested field names. On mod_php, PHP demonstrated code execution with default limits, before any application code runs.

CVE-2026-109619: state that outlives its request

A long-lived PHP worker serves many requests. Some of its global pointers refer to memory that belongs to one request. Normally those pointers are reset at the end of the request. A fatal error, a timeout or an out-of-memory event can skip that reset, the memory is freed, and the next request served by the same worker uses the stale pointer before startup reinitializes it.

The routes PHP confirmed are mod_php with .htaccess php_value directives that raise a warning before startup, PHP 8.5's fatal_error_backtraces, and session.upload_progress.

Is it being exploited?

CISA says yes, and the KEV listing is what drives most patch deadlines. The public record is more mixed, and it is worth knowing why:

• watchTowr reported honeypot exploitation on 21 October but has not published the evidence.
• Huntress saw no exploitation across its customers that day.
• Unit 42 linked an incident to php2shell, then withdrew that attribution on 25 October.

None of that changes the decision. The fix is a routine point release, and the preconditions on mod_php are minimal.

Check your exposure

Find the version and the SAPI each site actually uses, not just the CLI on the host:

# The PHP the web server runs may differ from the CLI.
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'
 
# Is PHP loaded into Apache (mod_php)?
apachectl -M 2>/dev/null | grep -i php
 
# Which FPM pools are running, and as whom?
ps -eo user,pid,cmd | grep '[p]hp-fpm'

For each site, a phpinfo() page behind authentication, or your configuration management inventory, tells you the server API and loaded .ini files.

Fix it

Upgrade to the fixed release for your branch and restart every PHP process: Apache for mod_php, each FPM pool for FPM. Container images need a rebuild, not just a restart.

If you need hours rather than minutes, PHP's advisories list configuration that lowers the risk. Set it in server configuration, because ini_set() from application code runs too late to help:

; Removes one confirmed route for CVE-2026-109619.
session.upload_progress.enabled = 0
 
; PHP 8.5 only.
fatal_error_backtraces = 0
 
; Keep request bodies small (8M is PHP's default; go lower where you can),
; and enforce multipart limits at the proxy as well.
post_max_size = 8M

PHP's advisory also suggests setting memory_limit = -1 with php_admin_value, and warns against the opposite instinct: capping memory with RLIMIT_AS or RLIMIT_DATA triggers the bug rather than containing it.

Detect attempts and compromise

Published guidance points at three signals:

• Process trees. A PHP worker that starts sh, curl, wget or nc, or a command line containing /dev/tcp/ or mkfifo. This is the highest-value alert, because it fires on success whatever the delivery route.
• Request shape. Very large or deeply nested multipart requests, especially to endpoints that never accept uploads.
• Worker health. Bursts of worker crashes or memory-limit errors in the PHP and web server logs.

CISA has published a Sigma rule for php2shell in its SIGMA_Rules repository, and network vendors have shipped signatures. If any of these fired before you patched, treat the host as compromised: the attacker ran as the web server user and could read everything that user can.

Beyond this patch

php2shell is a reminder that "unauthenticated" and "no application bug required" can coexist. The durable lessons are inventory and verification: know which SAPI every site runs, and confirm a fix with evidence rather than a version string. Rokkhe's retests do the second part for findings it has reproduced; how a retest verifies a fix explains what that evidence looks like.