Skip to content

Response, New York. Noah Park: Check Point Patches Actively Exploited Management Server Path Traversal. Detection, Dallas. Ava Okello: Report Finds Nearly Half of Deployed Detections Need Attention Before SOCs Can Trust Them.

SOCtember

Always First. Fast SOC News.

Wiz chart titled "Percentage of Organizations Significantly Affected by PHP2Shell," showing the share falling from 100% on Oct. 22 to 52.1% by late October, labeled a 47.9% decrease since the peak.
Chart: Wiz Research, "PHP2Shell: Exploitation Attempts and Remediation Trends," Oct. 27, 2026 (fair use). Share of significantly affected organizations after disclosure.

Response

Wiz Says Exposed Machines Vulnerable to PHP2Shell Fell About 67% in Days, While Public Exploit Kits Still Fail to Finish the Memory Leak

One week after disclosure, Wiz telemetry shows roughly 67% fewer distinct internet-exposed machines still vulnerable and a 47.9% drop in significantly affected organizations. In the same window, open-source exploit kits exhausted PHP memory on Wiz honeypots but never leaked the addresses needed for a working shell.

Noah Park, ResponseNew York6 min read

NEW YORK - One week after PHP2Shell's public disclosure on Oct. 21, Wiz Research says the number of distinct internet-exposed machines still vulnerable has fallen by about 67%, and the share of organizations with at least one exposed vulnerable instance is down about 47.9%. In the same window, the open-source exploit kits Wiz captured on its honeypots have exhausted PHP's memory without finishing the heap leak that a working remote shell needs.

The update, published Oct. 27, is a follow-on to Wiz's earlier report on CVE-2026-109618 and CVE-2026-109619. It mixes telemetry on how fast exposure is shrinking with a close read of the requests that have actually hit Wiz sensors. Wiz says it has not seen a successful end-to-end exploit in its own telemetry, even as partners have privately shared working exploits and Adel Karimi's public honeypot report remains the strongest open evidence of confirmed shells.

Exposure is falling, not gone

Among vulnerable internet-exposed machines, the share running PHP 7.3 or earlier dropped from 8.3% to 5.7% over five days. Wiz treats that as a signal that older builds without official backports are being retired or taken offline. One week after disclosure, less than 53% of the initially affected organizations in Wiz's dataset still show a vulnerable, internet-exposed instance. PHP itself remains in use at 65% of organizations in that dataset, so the residual surface is still large even after the steep early decline.

Wiz is careful about what the curve does not prove. The chart shows the overall trend; it does not break out how much of the drop came from patching, upgrading, retiring machines or simply closing internet exposure, and scan coverage can move the numbers.

What the kits are actually doing

Wiz groups the traffic into two buckets: attempts that use the PHP2Shell memory-corruption mechanism, and PHP2Shell-branded tools that instead rely on classic session poisoning plus a separate local file inclusion bug.

Wiz honeypot capture of the current-chain Stage A1 request: a chunked multipart POST with a null-byte PHPSESSID, 860 empty nested file parts and padding fields that consistently exhaust PHP's memory limit.
Screenshot: Wiz Research, Oct. 27, 2026 (fair use).Stage A1 of the current open-source exploit chain, as seen on a Wiz honeypot.

The older "legacy" chain, archived under legacy-8m in the public kit, sent a multipart body with 1,005 parts and a roughly 12 MB padding field. On Wiz's honeypot it never reached the intended session-reset path: the declared Content-Length of 12,655,437 bytes exceeded the configured 8 MB post_max_size, so PHP skipped the body. A later Roundcube-targeted run from the same chain stalled Apache workers but still failed to trigger the memory-exhaustion condition the kit needs.

The newer chain, built from pure/mk_a1.py and pure/mk_leak_b.py, got further. Stage A1 consistently returned HTTP 500 with a fatal "Allowed memory size ... exhausted" error. Stage B1, which is supposed to leak heap and libphp addresses through a PHPSESSID cookie so the final stage can build a shell, never produced a usable leak in any run Wiz captured. Most B1 connections closed without a response; one returned a normal 32-character session cookie. None of the sources then sent the final exploit stage.

Wiz honeypot capture of a worker-pinning stall: a POST that declares a 1,048,576-byte body, sends a single byte and holds the connection open so other Apache children stay busy.
Screenshot: Wiz Research, Oct. 27, 2026 (fair use).Incomplete request used to pin Apache workers beside the exploit stages.

Reliable worker pinning remains a second barrier. Consecutive exploit requests must hit the same Apache child while stale session state still points at freed memory. One address, 178.249.214[.]6, a VPN exit, opened 399 stalled connections and 400 GETs before sending the stages. Wiz says request timeouts and internet latency were enough, in its own testing, to break the chain against anything other than a favorable single-worker lab layout.

Branded tools that are not PHP2Shell

Separately, Wiz saw Go ports of an older session-poisoning kit that wrote PHP into a session file through PHP_SESSION_UPLOAD_PROGRESS and then included that file through an lfi_sink.php endpoint that exists only in the PoC's lab. Despite the PHP2Shell name in the User-Agent and boundary string, those requests do not exercise either CVE. A padded variant tripped Wiz's memory-exhaustion detection without achieving code execution.

Wiz indicators-of-compromise table listing IPv4 addresses first seen between Oct. 21 and Oct. 26, 2026, labeled as exploitation attempts, scanner-plus-exploitation attempts, a VPN exit and one C2 payload server.
Table: Wiz Research, Oct. 27, 2026 (fair use).IPv4 indicators from the honeypot and scanner traffic Wiz attributes to PHP2Shell-related activity.

The report lists nine IPv4 indicators with first-seen dates from Oct. 21 through Oct. 26, including 85.11.187[.]35 (session-poisoning kit), 3.37.227[.]134 (legacy chain), 178.249.214[.]6 (VPN worker-pinning), 31.56.197[.]72 (C2 / payload server) and 15.204.59[.]70 plus 162.35.99[.]94 (scanners that Wiz says did reach shells on Adel Karimi's honeypot, a data point that helped push the CVEs onto CISA's Known Exploited Vulnerabilities list).

What response teams should do with this

The practical reading for a SOC is twofold. First, the remediation curve is real: internet-exposed vulnerable PHP is shrinking fast, so keep pushing patches, upgrades and exposure cuts rather than waiting for a perfect exploit kit. Second, do not treat "no public general PoC" as safety. Wiz has privately reviewed working exploits, Karimi's honeypot already showed shells on a single-worker mod_php layout, and the public kits are failing on the leak and pinning steps that skilled operators can harden. Hunt for the multipart shapes in the report (null-byte PHPSESSID, hundreds of nested empty file parts, stalled Content-Length bodies of about 1 MB), for web servers spawning shells, and for the IPs above, while treating every remaining internet-facing PHP instance as overdue for the Oct. 21 security updates.

Sources:


Noah Park covers incident response and blue-team operations for SOCtember from New York.

Related stories

Response desk