Wiz: no successful PHP2Shell exploits in the wild as exposed systems drop 67%

One week after the PHP2Shell vulnerabilities were disclosed, Wiz reports that it has yet to observe a single successful exploitation in the wild, even though attackers are actively trying. The company's telemetry also shows that exposure to the two flaws, CVE-2026-109618 and CVE-2026-109619, is shrinking quickly following public disclosure on October 21, 2026.

Exposure is falling fast

According to Wiz, the daily count of distinct internet-exposed machines vulnerable to PHP2Shell has fallen by roughly 67% in the days since disclosure. The number of significantly affected organizations, defined as those with at least one exposed and vulnerable instance, dropped by about 47.9%, leaving less than 53% of initially affected organizations still vulnerable after one week.

Wiz also notes that among vulnerable exposed machines, the share running PHP 7.3 or earlier, versions that did not receive official security backports, declined from 8.3% to 5.7% over five days. For context, the company's data shows PHP in use at 65% of organizations in its dataset. Wiz attributes the overall decline to a combination of patching, upgrading, retiring affected machines and restricting internet access, while cautioning that its figures do not establish how much each approach contributed.

Attackers are trying, but the chains break

Wiz has captured attempts from two variants of an open-source exploit kit, and neither completed the exploit chain. The older, legacy variant, first seen hitting a PHP-CGI honeypot from IP 3.37.227.134, sent a multipart request with 1,005 parts and roughly 12 MB of padding. That exceeded the honeypot's 8 MB post_max_size limit, so PHP never processed the body. A later attempt against a Roundcube honeypot, from 103.151.172.95, stalled connections to occupy Apache workers and sent heap-shaping requests containing 1,001 fields of 3,000 bytes each, but never triggered the memory-exhaustion condition the exploit requires.

The newer variant got further. Its first stage, a chunked multipart request with a null-byte session ID and 860 empty file parts using deeply nested array names, consistently exhausted PHP's memory, with every captured request returning an HTTP 500 and a memory-limit error. To improve the odds that consecutive requests land on the same Apache worker, the kit holds other workers open with incomplete connections; one address, 178.249.214.6, a VPN exit node, opened 399 such connections alongside 400 GET requests before sending the exploit stages.

The follow-up leak stage, sent roughly a second later, failed in every run Wiz captured. That stage is designed to make PHP write reclaimed heap contents into a PHPSESSID response cookie, from which the kit extracts heap and libphp addresses to prepare the final stage. In all but one observed run the connection closed without a response, and the remaining run returned a normal 32-character session cookie. No source ever sent the final exploit stage. Wiz also observed tools branded PHP2Shell that were unrelated to the vulnerabilities, relying instead on session poisoning and a separate local file inclusion flaw.

Why the public exploits stall

Building an exploit that works reliably across PHP versions and deployment configurations is difficult, Wiz explains. The kit's leak stage was calculated for the official php:8.4.26-apache image with a 128 MB memory limit, while the Roundcube honeypot ran the same PHP version from a different build, with additional extensions and a 64 MB limit, differences that affect heap layout and memory reuse. Worker pinning adds another hurdle: consecutive requests must reach the same Apache child process while the stale session state persists, and timeouts, latency and worker availability can break the sequence. In Wiz's own testing, request timeouts combined with network latency were enough to stop the chain from completing over an internet connection.

That does not mean the bugs are unexploitable. Wiz says partners have privately disclosed exploits that work against a variety of targets, and the company has demonstrated its own successful exploitation.

Why it matters

The absence of a working, general-purpose public exploit has given defenders an unusually clean patch window, and the 67% drop in exposed machines suggests many organizations are using it. But Wiz expects the technical barriers to diminish over time, and working exploits already exist in private hands. For any organization still running an exposed, unpatched PHP instance, the safe assumption is that the gap between a failing public proof of concept and a reliable attack kit is closing.