PHP2Shell: CVE-2026-109618 and CVE-2026-109619 — Critical PHP RCE, Patch Today

The PHP security team did something unusual on October 20: it pre-announced an emergency release before telling anyone what it fixes. Two vulnerabilities, both rated CVSS v4.0 9.2 (critical), fix scheduled for Wednesday, October 21, 2026 at 14:00 UTC. Within hours the embargo collapsed — a Hacker News post, screenshots of an exploit tool named "PHP2Shell," and a confirmation from watchTowr that the bugs are real and remotely exploitable. The release was pulled forward a full day. If you run PHP anywhere on an internet-facing path, the window between "patch exists" and "patch is applied everywhere" is where this story gets decided, and that window is measured in minutes.

Developing story — first published 12:29 CEST (10:29 UTC), October 21, 2026. Updated as the vendor and CISA publish more.

At a glance

CVE	CVE-2026-109618 · CVE-2026-109619 (identifiers from the leaked advisory; PHP's own notice lists neither; no NVD record yet)
Product / affected versions	PHP (interpreter core) · reported to affect every release from PHP 5.4.0 onward per Sansec and the leaked tool's banner; official affected list pending with the release
Fixed in	Not yet released · security release scheduled 2026-10-21 14:00 UTC; PHP 8.1 and older are out of support and will not get an official fix
CVSS	9.2 Critical (CVSS v4.0) · scored by the PHP security team; CERT-EU reads the vector as unauthenticated
Exploited in the wild	Not confirmed · watchTowr and Huntress report none; Sansec cites Cloudflare attack traffic observed from 2026-10-21 07:43 UTC
CISA KEV	Not listed (as of 2026-10-21)
Public PoC	None public as of 2026-10-21; a private tool "PHP2Shell" (credited to Calif.IO) leaked as a screenshot; watchTowr says it reproduced CVE-2026-109618 but is withholding details
Official advisory	https://www.php.net/archive/2026.php

What happened: PHP2Shell leaked before the fix

PHP ships security fixes on a coordinated schedule. This time the schedule broke. The official PHP pre-announcement on October 20 gave only the essentials: an upcoming release addressing "two critical vulnerabilities, both rated CVSS v4.0 9.2," with full details, affected versions, and fixed versions held back until the release itself. It also carried a tell — the team reserved the right to ship earlier "should details of either vulnerability become public, or should evidence of active exploitation appear in the wild."

Both conditions started to come true the same day. According to Sansec's writeup, a Hacker News post on October 20 flagged the coming disclosure, was removed, and the screenshots spread anyway — including one of an offensive tool called PHP2Shell, credited to Calif.IO, whose banner claims it works against every PHP release from 5.4.0 on. SecurityWeek reported that watchTowr's Benjamin Harris confirmed his team reproduced CVE-2026-109618 and that the bugs are genuine remote code execution. The CVE identifiers trace to the leaked material; PHP's notice lists neither, and neither is in NVD yet. The result is the worst possible disclosure shape: a confirmed, critical, unauthenticated RCE in one of the most widely deployed pieces of server software on earth, no fix yet for most people, and a working exploit already in private hands.

Who is exposed, and how to check

PHP is not one product you patch once. It is an interpreter bundled into CMS platforms, e-commerce stacks, hosting control panels, and vendor appliances. Sansec says the flaws affect "all web servers running PHP 5.4 or later," which sweeps in Magento, Shopware, and WooCommerce. Huntress frames it the same way — RCE "in PHP's core" — and both stress that the affected-version list is unconfirmed until the release.

Check what you actually run, not what you think you run:

• php -v on every host, and the version your web SAPI uses — CLI and FPM can differ. For PHP-FPM, check each pool.
• The PHP bundled with your CMS or commerce platform, which is often older than the system PHP.
• Control panels (cPanel, Plesk), which ship their own PHP builds.
• Containers and base images: docker image inspect the PHP layer; a rebuilt image is the only real fix there.
• End-of-life PHP. PHP supports only 8.2 and later, so 8.1 and older will get no official patch — those hosts need a supported upgrade, a vendor backport, or removal from the internet.

Remediation

This is an interpreter-level bug. You cannot fix it in your application code — the vulnerable path runs inside PHP itself, before your app or any PHP-level WAF executes. That constrains what "mitigation" can mean.

1. Am I affected? Inventory every PHP install per the list above. Treat any internet-reachable PHP as in scope until the official affected-version list says otherwise.

2. Patch — the moment it lands. The fixed versions publish with the release at 14:00 UTC on October 21. Patch internet-facing systems first. Watch the official announcement for the exact fixed build per branch and apply it; do not trust a third-party summary for the version number. Note that some distributions and repositories lag — Sansec flags that Remi's repository will not have updates on release day — so confirm your package source actually carries the fixed build.

3. Can't patch yet? Compensating controls (no guarantee). Sansec's stopgap, while you wait, is to narrow PHP's session and upload handling in php.ini:

session.upload_progress.enabled = 0
session.use_strict_mode = 1

For PHP-FPM, set these as pool directives (e.g. in www.conf) so they can't be overridden:

php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[session.use_strict_mode] = on

Reload the workers (systemctl reload php8.3-fpm) and verify the values inside a real request. Two caveats Sansec is explicit about: strict session mode does nothing if your sessions live in Redis or a database, and a PHP core developer has called patching the only real mitigation — do not rely on the upload-progress toggle alone. For end-of-life PHP you cannot patch, the honest control is to take it off the internet or put it behind a VPN or a network WAF.

"You cannot fix it from within your store codebase." — Sansec, on why this has to be solved at the infrastructure layer, not the app layer.

4. Hunt for compromise. See the detection section below.

5. Eradicate and verify. If you find signs of exploitation: isolate the host, preserve web server and PHP logs before they rotate, and hunt for web shells, unexpected files in the web root, new cron jobs or scheduled tasks, and new accounts (per Huntress). Patch or rebuild, then rotate every credential the PHP process could read — database passwords, API keys, session secrets — because a successful RCE runs as the web user and can read all of them. Re-test the exact entry path afterward; a higher version string is not proof the hole is closed.

Detection and hunting

No IOCs, log lines, or paths have been published yet, and we will not invent any. What defenders can watch for now is behavioral, drawn from Huntress's rapid response: RCE against a web interpreter nearly always surfaces as the interpreter spawning a child it should never spawn.

• PHP processes (php-fpm, php-cgi, httpd, apache2) launching sh, bash, cmd.exe, or powershell.exe — classic web-shell / command-execution behavior (MITRE ATT&CK T1190 initial access, T1505.003 web shell, T1059 command execution).
• Those same processes launching interpreters (python, perl) or download/transfer tools (curl, wget, nc, certutil.exe).
• Command lines containing /dev/tcp/, fsockopen, or mkfifo — reverse-shell primitives.
• Reconnaissance from a web host: whoami, id, uname -a, ipconfig.

On Linux servers without EDR, Huntress points to Florian Roth's process-watcher run in observe mode. The catch with all of it: these signals fire after code is already executing. On a flaw where mass exploitation is expected within minutes of the patch, after-the-fact process telemetry is a race you are structurally behind on.

What is not known yet

• The root cause of either CVE. The recommended php.ini stopgap points at PHP's session upload-progress / multipart handling, and one report describes CVE-2026-109618 as a use-after-free — but PHP has not confirmed the component, and we treat that as unverified.
• The exact affected and fixed versions, which publish with the release.
• Confirmed in-the-wild exploitation. watchTowr and Huntress report none as of writing; Sansec cites early attack traffic seen by Cloudflare at 07:43 UTC on October 21, which may be scanning rather than working exploitation. There is no public PoC yet.
• Whether CISA adds the pair to the KEV catalog once the fix and exploitation picture firm up.

We will update this post as PHP, CISA, and the researchers publish more.

Surviving the 15-minute window

Sansec's warning — mass exploitation "likely within 15 minutes" of release — is the real problem statement. Nobody patches a fleet of web servers, bundled runtimes, and EOL hosts in fifteen minutes. So the question is not only "did I patch" but "will I see the instant someone lands the exploit on a box I haven't reached." As the detection section admits, host-side telemetry catches that only after the shell is already open.

This is the case Zero Hunt's AI Traffic Analysis was built for: a deep-learning model with four inference heads (suspicious traffic, malware classification, attack-type identification, application fingerprinting), trained on billions of PCAP sequences, running at a 2.7+ Gbit/s baseline locally on the appliance GPU. The exploitation attempt, the web shell's first callback, tool staging over curl/wget, the reverse-shell beacon — all cross the wire while it is happening, not in next morning's SIEM digest. When the gap between patch and exploit is minutes, seeing the attempt on the network is the difference between an incident you contain and one you read about later.

The patch race is the other half, and it's a prioritization problem. Zero Hunt's AI Remediation Advisor ranks by real exploitability — KEV first, then what a campaign proved reachable, then CVSS and EPSS — gives the exact fix with rollout/rollback notes and a compensating control for hosts you can't patch today, then re-verifies with the same proof that demonstrated the exposure. For EOL PHP that will never get an official build, that re-verification is what tells you the network control in front of it actually holds.

Zero Hunt runs as an autonomous AI red team, on-premise on its own private models, with a human in the loop for every action that matters. To see where PHP hides in your estate before 14:00 UTC, start with our guide to automated penetration testing, and our team can walk through it. For the broader pattern, see our earlier analysis of wp2shell in WordPress core.