PHP2Shell: Two Leaked Critical PHP Core RCEs, CVE-2026-109618 and CVE-2026-109619, Ahead of the 21 October Fix

The PHP security team published advance notice on php.net on 20 October 2026 of a security release "scheduled for Wednesday, 21 October 2026 at 14:00 UTC." The notice says it "addresses two critical vulnerabilities, both rated CVSS v4.0 9.2," and that full details, affected versions and fixed versions will be published with the release. It also says the team reserves "the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild." The notice is at php.net.

Details did become public, in part. The two CVE IDs, CVE-2026-109618 and CVE-2026-109619, leaked the same day, and researchers say a working exploit tool exists. This post covers what is known and who said it, what defenders are watching for before the fix, and what RedEye expects next.

The leak and the timeline

• 20 October: A Hacker News "Tell HN" post by user petecooper (item 50167754, since deleted) said two critical PHP remote code execution flaws rated CVSS 10.0, affecting PHP back to version 5, would be disclosed on 22 October. It named CVE-2026-109618 and CVE-2026-109619. (BleepingComputer, Lawrence Abrams.)
• Planned: Coordinated disclosure had been set for Thursday 22 October at 11:00 ET. watchTowr said: "We were all supposed to wait until Thursday at 11am ET." (BleepingComputer; threatlandscape.io timeline.)
• 20 October: PHP published its advance notice and moved the release up a day.
• 21 October, 14:00 UTC: Scheduled release, with affected and fixed versions.

The severity numbers do not match. PHP rates both flaws 9.2 on CVSS v4.0. The leaked post and watchTowr's early comments said 10.0.

What is known, and from whom

watchTowr

watchTowr CEO Benjamin Harris confirmed the flaws are real and said the company reproduced CVE-2026-109618. watchTowr is withholding details until the fix ships and says it has seen no in-the-wild exploitation. It did not discover the bugs, and the original researchers are not yet public. Its first post mistyped the IDs as CVE-2926; that has been corrected.

Sansec

The Sansec Forensics Team says a screenshot of an exploit tool named PHP2Shell, credited to Calif.IO, leaked alongside the advisory. Its banner claims it works against every PHP release from 5.4.0 on. Sansec says the flaws affect all web servers running PHP 5.4 or later, including Magento, Shopware and WooCommerce stores. Because the attack targets PHP itself, before store code or any application-level shield runs, Sansec says the fix is infrastructure-level and cannot be applied from the application. It says PHP 8.1 and older get no official fix, since PHP supports 8.2 and later, and that it expects mass attacks within 15 minutes of the release. Source: sansec.io.

Huntress

Huntress Rapid Response (John Hammond, with Lindsey Welch and Ben Nahorney) wrote on 20 October that it had seen no exploitation in Huntress partner environments as of that date. It tells defenders to inventory every PHP install, including vendor software that bundles php-cgi.exe or php.exe on Windows, control panels such as cPanel and Plesk, appliances, and PHP applications such as WordPress, Drupal, Joomla and Magento. Huntress says it will publish Sigma and YARA rules to huntresslabs/threat-intel once details are public, and that indicators of compromise are still to be determined. Source: huntress.com.

Mallory

Mallory published numbers on 20 October based on Shodan's "X-Powered-By: PHP/<major.minor>" header per branch. Its read is that expected fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, citing the PHP notice. PHP itself has not published version numbers, so treat those four as expected, not confirmed. Source: mallory.ai.

Who is exposed

Mallory counts about 1.5 million internet-facing hosts that report a PHP version. Of those, 883,717 run a branch that will get no fix, about 59 percent:

• PHP 5.x: 368,570 hosts
• PHP 7.x: 329,358 hosts
• PHP 8.0 and 8.1: 185,789 hosts

Roughly 740,000 more hosts hide their version. Shared hosting means the number of affected sites is larger than the number of hosts. Sansec's point that the flaw sits below application code means a hardened store or a web application firewall in front of the code is not the same as a patched PHP.

One group's hypothesis, not confirmed by PHP

Andrew Dorman, on LinkedIn, and JackalSyn, in a write-up from the same group, say that based on their own read of php-src the vulnerable path is the session.upload_progress handler for multipart form-data (rfc1867) in ext/session/session.c. They say it has existed since PHP 5.4 and is enabled by default: the compiled-in default is On, and the sample php.ini ships the line commented out. It runs before application code, so on their reading it is reachable before authentication on a default configuration. They describe two heap use-after-free primitives.

The group's reported stopgaps are to set session.upload_progress.enabled to Off and reload PHP-FPM or the web server, which by their own account closes one of the two likely paths, and to tighten or rate-limit multipart POSTs at a WAF or reverse proxy for endpoints that do not take uploads. These are the group's suggestions, reported here as such, not a vendor mitigation. The official advisory is the thing to follow.

What defenders are watching for before the fix

Huntress describes the detection shape it expects, which does not depend on the root cause:

• PHP workers (php-fpm, php-cgi, php-cgi.exe, httpd, apache2) launching shells (sh, bash, cmd.exe, powershell.exe), interpreters (python, perl) or download and network tools (curl, wget, nc, certutil.exe).
• Reverse-shell patterns such as /dev/tcp/, fsockopen and mkfifo.
• Reconnaissance commands run from web servers, such as whoami, id, uname -a and ipconfig.

For Linux hosts without EDR, Huntress points to Florian Roth's process-watcher.

KEV outlook: RedEye's own assessment

This section is RedEye's assessment, not a CISA statement. CISA's three tests for the Known Exploited Vulnerabilities catalog are a CVE ID, a clear remediation and reliable evidence of active exploitation. The first is met; the second lands at 14:00 UTC today. The closest precedent is CVE-2024-4577, the PHP-CGI argument injection disclosed on 6 June 2024, exploited by ransomware within 48 hours and added to KEV on 12 June 2024, six days later. This one has a wider blast radius, so RedEye expects a KEV listing within days of the fix. RedEye's feed carries a KEV fast lane that flips the moment CISA lists it.

Two things could slow exploitation. PHP's 9.2 rather than 10.0 hints at a precondition, such as a SAPI, a configuration or a request shape, that the leak does not show. And nobody outside the embargo has published a root cause.

After 14:00 UTC: what this post will add

Last updated 21 October 2026, before the release. After 14:00 UTC this post will be updated with the affected versions, the fixed versions and, if PHP or the reporting researchers publish one, the root cause, and will say whether the session.upload_progress hypothesis above held up.

How this looks in Caver

In Caver, the signal to watch is a notable on OCSF process activity where the parent is a PHP worker and the child is a shell, an interpreter or a download tool, the same shape Huntress describes. The KEV fast lane on the detection feed flips when CISA lists either CVE. The vSOC catches the drill-down: which host, which web worker, which command, and what it reached out to next.