Wiz Details Failed PHP2Shell Exploit Attempts and Falling Exposure

Summary

Wiz observed PHP2Shell attempts that triggered memory exhaustion but did not complete the exploit chain in its telemetry. Exposed vulnerable machines fell about 67% after disclosure, though the vulnerabilities remain a risk.

Key points

Wiz observed a roughly 67% decrease in distinct internet-exposed machines vulnerable to PHP2Shell after its October 21, 2026 disclosure; the data does not identify which remediation measures drove the change.
The newer exploit-kit variant consistently triggered PHP memory exhaustion, but its follow-up memory-leak stage failed in every captured run.
A legacy exploit attempt exceeded the honeypot's 8 MB request-size limit; another attempt did not show evidence of reaching its intended memory-exhaustion condition.
The exploit chain depends on consecutive requests reaching the same Apache child process and on deployment-specific memory and heap behavior, complicating reliable exploitation.
Some PHP2Shell-branded tools used session poisoning and required a separate vulnerable local-file-inclusion endpoint, rather than exploiting the named vulnerabilities.
Wiz saw no successful end-to-end PHP2Shell exploitation in its telemetry. It cites Adel Karimi's honeypot report as public evidence of successful exploitation, while noting that the tested configuration does not establish reliability across deployments.
Wiz says applying PHP security updates or otherwise reducing exposure remains essential.

Article Details

Attack Vectors: Exploit attempts against PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 used crafted multipart requests to trigger PHP memory exhaustion, followed by a stage attempting to leak process memory.
The exploit kit attempted to keep consecutive requests on the same Apache child process by opening incomplete requests that occupied other workers.
A separate PHP2Shell-branded tool attempted session poisoning by writing PHP code through the upload-progress feature, then including the session file through an LFI endpoint. The article says this required a vulnerable application endpoint and was unrelated to the PHP vulnerabilities.
Defensive Notes: Apply PHP security updates or remediate exposure through patching, upgrading, retiring affected machines, or restricting internet access.
The article reports that exploit reliability can depend on PHP builds, memory limits, extensions, worker behavior, request timeouts, and network latency.

Indicators of compromise

Type	Indicator	Context
IPV4	`103[.]151[.]172[.]95`	Source IP of a later exploitation attempt using the legacy chain against the Roundcube honeypot.
IPV4	`135[.]136[.]19[.]197`	Listed as a scanner and exploitation-attempt source; the article identifies it as a VPN.
IPV4	`15[.]204[.]59[.]70`	Source IP of a failed exploitation attempt.
IPV4	`162[.]35[.]99[.]94`	Source IP of a failed exploitation attempt.
IPV4	`172[.]206[.]2[.]199`	Listed as a scanner and exploitation-attempt source.
IPV4	`178[.]249[.]214[.]6`	Source IP that opened numerous incomplete connections alongside GET requests before sending exploit stages; the article identifies it as a VPN exit node.
IPV4	`3[.]37[.]227[.]134`	Source IP of an exploitation attempt using the legacy PHP2Shell exploit chain.
IPV4	`31[.]56[.]197[.]72`	Identified in the article's IOC table as a C2 payload server.
IPV4	`85[.]11[.]187[.]35`	Source IP of a PHP2Shell-branded session-poisoning and LFI exploitation attempt.