PHP2Shell: verify your runtime patches Read guidance
CVSS 9.2 · CRITICAL
Codename: PHP2Shell

PHP2Shell: two flaws that hand attackers your server

On October 21, 2026, the PHP project shipped emergency fixes for two memory-corruption vulnerabilities in the language runtime itself. Both can be triggered by an unauthenticated network request, and both can end in remote code execution — no login, no user interaction, no application bug required.

CVE-2026-109618

Out-of-memory corruption during request parsing

PHP enforces its memory limit by aborting the current request the moment an allocation fails. The problem: in several code paths — notably while parsing a multipart form upload — PHP has already marked internal request data as "ready" before every allocation behind it has completed. When the memory abort interrupts things, that half-built state is never rolled back.

The request's cleanup routine then walks the uninitialized memory as if it were valid — reading, branching, and freeing it. Because the abandoned memory may still contain data from earlier allocations that the attacker influenced through a crafted HTTP request, this corruption can be steered toward code execution.

CVE-2026-109619

Stale state between requests on the same worker

PHP workers reuse themselves across requests, and some global state temporarily points into memory owned by a single request. If a fatal error interrupts the reset — or the state is repopulated after being cleared — the worker keeps pointing at memory that has already been freed. The next request handled by that worker reads or acts on the stale state before normal initialization catches up, producing a classic use-after-free with attacker-controlled contents.

Who is most exposed?

Web-serving PHP deployments should be assessed, including FPM and mod_php. Exploitability depends on configuration; the upstream advisory identifies mod_php as the highest demonstrated risk.

Affected versions, fixed versions

PHP branchVulnerable rangeFixed in
PHP 8.58.5.0 – 8.5.118.5.12
PHP 8.48.4.0 – 8.4.268.4.27
PHP 8.38.3.0 – 8.3.358.3.36
PHP 8.28.2.0 – 8.2.348.2.35
PHP 8.1 and olderOutside upstream supportVerify vendor backport

Older branches may have vendor or source backports. Verify the exact installed package, not just its base version, and plan a supported upgrade.

How to fix it — in the right order

STEP 1

Upgrade PHP (the real fix)

Move every runtime to a fixed release. This is the only complete remediation, and the only one that survives new exploit variants.

STEP 2

Filter malicious requests (stopgap)

Request filtering can reduce some exposure. Verify coverage with your provider; WAF rules are not a substitute for patching.

STEP 3

Isolate what can't be patched yet

If a system cannot be upgraded this week, restrict it to trusted networks until it can. Preferably both.

STEP 4

Check the forgotten corners

CLI scripts that handle uploads, queue workers, cron jobs and staging copies run PHP too — and are routinely missed in fleet patches.