php2shell: two critical RCEs in PHP core — lab demo and how to fix CVE-2026-109618 and CVE-2026-109619
---
published: true
tags: security, php, cybersecurity, rce
description: "Two critical RCEs emergency-patched in the PHP core — session.upload_progress, on by default since 5.4. The lab: attack surface, A/B demo, detection, and the fix."
series: black box
---
> Two remote code execution vulnerabilities were just emergency-patched in the PHP core: CVE-2026-109618 and CVE-2026-109619, CVSS v4.0 9.2/10 each, nicknamed php2shell. They potentially affect every PHP release since 5.4 — the one from 2012. Details leaked ahead of the embargo, PHP moved its security release up, and we're showing everything in a lab: the attack surface, the demonstration, and above all how to fix.
⚠️ The full lab (Docker, race harness, AddressSanitizer A/B proof — now with a stock-WordPress target on the frozen vulnerable PHP) lives under. Local target only, never aimed at third-party systems — and the PoC is built from the official patch diff at release time, not from the leaked tooling.
{% embed github slabbdev/php2shell-cve-2026-109618-109619 %}
Timeline of a leak
- Oct 20, morning: a "Tell HN" post (since deleted) reveals two PHP RCEs rated CVSS 10.0. Screenshots spread on X and Mastodon, the reserved CVE IDs get quoted.
- Oct 20: watchTowr publicly confirms the bugs are real. PHP publishes an advance notice: CVSS v4.0 9.2 each, security release on Oct 21 at 14:00 UTC — moved up a day precisely because details leaked.
- Oct 21: an exploit video "php2shell" (credited to Calif.IO) and a PoC briefly circulate before being pulled. No confirmed in-the-wild exploitation at the time of writing (Huntress), but Sansec expects mass exploitation within minutes of the patch going public.
The attack surface
<!-- [T0: replace with the official diff analysis. Below: public knowledge at leak time.] -->
The technical details that surfaced in the leak coverage describe "two heap use-after-free primitives in PHP's session.upload_progress handler".
What makes this serious: session.upload_progress.enabled is on by default on nearly every PHP install since 5.4. Which matches the leaked tool's claim exactly: "works against every PHP release from 5.4.0 on".
We verified that surface in the lab. A plain multipart POST carrying a PHP_SESSION_UPLOAD_PROGRESS=<key> field makes the server write an entry fully controlled by the attacker into its own session store:
array (
'upload_progress_fastkey' =>
array (
'start_time' => 1792574947,
'content_length' => 7284,
'bytes_processed' => 7284,
'done' => true,
'files' => array ( ... ),
),
)
That's the official upload-progress-bar feature — nobody enables it, nobody disables it, nobody watches it. And it's a permanent race between the streaming upload and the session lifecycle. Exactly where use-after-free bugs live.
<!-- [T0: full demo here — PoC, ASAN output on the vulnerable build, clean run on the patched build] -->
The lab demo
Setup: nginx + php-fpm 8.4 (Docker images digest-pinned pre-patch, pulled before the release), and a Python harness sending a throttled raw-socket multipart upload while a second flow disturbs the session lifecycle (destroy, regenerate, GC, double upload, client abort).
Two details make the race winnable in practice:
- The harness pads the multipart body with small form fields so the RFC 1867 parse loop dominates the race window instead of the network — bodies stay under post_max_size (8 MB by default), and the request streams chunk by chunk through fastcgi_request_buffering off.
- The slow upload is aimable at any endpoint (--path), not just a script the lab controls.
That second point is why the lab now ships a second target: stock WordPress on the same frozen vulnerable PHP — default config, no vulnerable plugin, no misconfiguration. The "your code never runs before the bug" claim, made concrete on the most-deployed PHP application on the web. Run it yourself (local only, 127.0.0.1):
git clone https://github.com/slabbdev/php2shell-cve-2026-109618-109619
cd php2shell-cve-2026-109618-109619/wordpress-demo
sh setup.sh # fetches WP + wp-cli, boots, installs, verifies
python3 ../harness/race.py --port 8080 --path /wp-login.php --modes "" --rounds 1
docker compose exec fpm cat /tmp/sess/sess_* # → an attacker-controlled upload_progress_<key> entry
The full chain on WordPress — race to RCE on wp-login.php, then the same harness landing clean on the patched build — is the next lab update, once the official diff is out.
<!-- [T0: A/B results — the UAF proven by ASAN on the vulnerable build, the same harness landing clean on the patched one. That's a demonstration, not a theory.] -->
Who is exposed
- Any unpatched PHP web server: php-fpm, mod_php, cgi. No account needed, no vulnerable application endpoint needed — the bug is in the core, and the exploit completes before your application code even runs. Application-level WAFs see nothing.
- End-of-life branches (≤ 8.2) get no official fix: a large chunk of the web has to migrate or rely on distro backports.
- [T0: exact patched versions per branch 8.3.x / 8.4.x / 8.5.x]
The fix, step by step
1. Inventory everything running PHP, including the embedded ones (apps shipping their own php.exe, cPanel/Plesk, containers):
php -v
php -i | grep -i 'upload_progress.enabled' # On = surface active (default since 5.4)
2. Update to the patched release of your branch:
<!-- [T0: distro commands — apt/dnf/alpine/brew, exact target versions] -->
3. EOL branches: migrating to a supported branch is the only real answer. Until then: network isolation plus detection (below).
4. Managed or shared hosting? Open the ticket now — ask your provider exactly when they deploy the patched packages and for which branches. "Soon" is not an answer.
5. ⚠️ session.upload_progress.enabled=Off is NOT a fix. It's a partial mitigation the public coverage says is insufficient — the PHP release managers were explicit that patching is mandatory.
Detecting an attempt
Watch for abnormal children of PHP workers: a php-fpm spawning sh, bash, nc, curl or python means it's already too late — but it's the signal. A quick triage on any box:
pstree -p | grep -A2 php-fpm # anything hanging off a worker that isn't a socket = look closer
Reverse-shell patterns in command lines: /dev/tcp/, mkfifo, fsockopen. On unmonitored Linux servers, a free process-watcher in observe mode is better than nothing until real EDR lands.
<!-- [T0: official Sigma/YARA rules (Huntress huntresslabs/threat-intel) + published IOCs] -->
TL;DR
Patch today, not tomorrow. The full diff analysis, PoC and proofs are in the lab repo: [T0: link].
Sources: official php.net notice · watchTowr · Huntress · Sansec · CERT-EU 2026-018 · [T0: official release notes & upgrade pages for 8.3 / 8.4 / 8.5]
7 reactions · 1 comment
Mentions
php2shell: two critical RCEs in PHP core — lab demo and how to fix CVE-2026-109618 and CVE-2026-109619 --- published: true tags: security, php, cybersecurity, rce description: "Two critical RCEs emergency-patched in the PHP core — session.upload_progress, on by default since 5.4. The lab: attack surface, A/B demo, detection, and the fix." series: black box --- > Two remote code execution vulnerabilities were just emergency-patched in the PHP core: CVE-2026-109618 and CVE-2026-109619, CVSS v4.0 9.2/10 each, nicknamed php2shell. They potentially affect every PHP release since 5.4 — the one from 2012. Details leaked ahead of the embargo, PHP moved its security release up, and we're showing everything in a lab: the attack surface, the demonstration, and above all how to fix. ⚠️ The full lab (Docker, race harness, AddressSanitizer A/B proof — now with a stock-WordPress target on the frozen vulnerable PHP) lives under. Local target only, never aimed at third-party systems — and the PoC is built from the official patch diff at release time, not from the leaked tooling. {% embed github slabbdev/php2shell-cve-2026-109618-109619 %} Timeline of a leak - Oct 20, morning: a "Tell HN" post (since deleted) reveals two PHP RCEs rated CVSS 10.0. Screenshots spread on X and Mastodon, the reserved CVE IDs get quoted. - Oct 20: watchTowr publicly confirms the bugs are real. PHP publishes an advance notice: CVSS v4.0 9.2 each, security release on Oct 21 at 14:00 UTC — moved up a day precisely because details leaked. - Oct 21: an exploit video "php2shell" (credited to Calif.IO) and a PoC briefly circulate before being pulled. No confirmed in-the-wild exploitation at the time of writing (Huntress), but Sansec expects mass exploitation within minutes of the patch going public. The attack surface <!-- [T0: replace with the official diff analysis. Below: public knowledge at leak time.] --> The technical details that surfaced in the leak coverage describe "two heap use-after-free primitives in PHP's session.upload_progress handler". What makes this serious: session.upload_progress.enabled is on by default on nearly every PHP install since 5.4. Which matches the leaked tool's claim exactly: "works against every PHP release from 5.4.0 on". We verified that surface in the lab. A plain multipart POST carrying a PHP_SESSION_UPLOAD_PROGRESS=<key> field makes the server write an entry fully controlled by the attacker into its own session store: array ( 'upload_progress_fastkey' => array ( 'start_time' => 1792574947, 'content_length' => 7284, 'bytes_processed' => 7284, 'done' => true, 'files' => array ( ... ), ), ) That's the official upload-progress-bar feature — nobody enables it, nobody disables it, nobody watches it. And it's a permanent race between the streaming upload and the session lifecycle. Exactly where use-after-free bugs live. <!-- [T0: full demo here — PoC, ASAN output on the vulnerable build, clean run on the patched build] --> The lab demo Setup: nginx + php-fpm 8.4 (Docker images digest-pinned pre-patch, pulled before the release), and a Python harness sending a throttled raw-socket multipart upload while a second flow disturbs the session lifecycle (destroy, regenerate, GC, double upload, client abort). Two details make the race winnable in practice: - The harness pads the multipart body with small form fields so the RFC 1867 parse loop dominates the race window instead of the network — bodies stay under post_max_size (8 MB by default), and the request streams chunk by chunk through fastcgi_request_buffering off. - The slow upload is aimable at any endpoint (--path), not just a script the lab controls. That second point is why the lab now ships a second target: stock WordPress on the same frozen vulnerable PHP — default config, no vulnerable plugin, no misconfiguration. The "your code never runs before the bug" claim, made concrete on the most-deployed PHP application on the web. Run it yourself (local only, 127.0.0.1): git clone https://github.com/slabbdev/php2shell-cve-2026-109618-109619 cd php2shell-cve-2026-109618-109619/wordpress-demo sh setup.sh # fetches WP + wp-cli, boots, installs, verifies python3 ../harness/race.py --port 8080 --path /wp-login.php --modes "" --rounds 1 docker compose exec fpm cat /tmp/sess/sess_* # → an attacker-controlled upload_progress_<key> entry The full chain on WordPress — race to RCE on wp-login.php, then the same harness landing clean on the patched build — is the next lab update, once the official diff is out. <!-- [T0: A/B results — the UAF proven by ASAN on the vulnerable build, the same harness landing clean on the patched one. That's a demonstration, not a theory.] --> Who is exposed - Any unpatched PHP web server: php-fpm, mod_php, cgi. No account needed, no vulnerable application endpoint needed — the bug is in the core, and the exploit completes before your application code even runs. Application-level WAFs see nothing. - End-of-life branches (≤ 8.2) get no official fix: a large chunk of the web has to migrate or rely on distro backports. - [T0: exact patched versions per branch 8.3.x / 8.4.x / 8.5.x] The fix, step by step 1. Inventory everything running PHP, including the embedded ones (apps shipping their own php.exe, cPanel/Plesk, containers): php -v php -i | grep -i 'upload_progress.enabled' # On = surface active (default since 5.4) 2. Update to the patched release of your branch: <!-- [T0: distro commands — apt/dnf/alpine/brew, exact target versions] --> 3. EOL branches: migrating to a supported branch is the only real answer. Until then: network isolation plus detection (below). 4. Managed or shared hosting? Open the ticket now — ask your provider exactly when they deploy the patched packages and for which branches. "Soon" is not an answer. 5. ⚠️ session.upload_progress.enabled=Off is NOT a fix. It's a partial mitigation the public coverage says is insufficient — the PHP release managers were explicit that patching is mandatory. Detecting an attempt Watch for abnormal children of PHP workers: a php-fpm spawning sh, bash, nc, curl or python means it's already too late — but it's the signal. A quick triage on any box: pstree -p | grep -A2 php-fpm # anything hanging off a worker that isn't a socket = look closer Reverse-shell patterns in command lines: /dev/tcp/, mkfifo, fsockopen. On unmonitored Linux servers, a free process-watcher in observe mode is better than nothing until real EDR lands. <!-- [T0: official Sigma/YARA rules (Huntress huntresslabs/threat-intel) + published IOCs] --> TL;DR Patch today, not tomorrow. The full diff analysis, PoC and proofs are in the lab repo: [T0: link]. Sources: official php.net notice · watchTowr · Huntress · Sansec · CERT-EU 2026-018 · [T0: official release notes & upgrade pages for 8.3 / 8.4 / 8.5]