PHP2Shell exploitation attempts have not succeeded and vulnerable hosts fell 67% after disclosure
The claim
The authors assert that no end-to-end PHP2Shell exploit has been observed in the wild and that the number of Internet-exposed vulnerable machines dropped by about 67% since the vulnerability disclosure.
Published as: “PHP2Shell: Exploitation Attempts and Remediation Trends”
So what
The lack of observed successful exploitation and rapid reduction in vulnerable hosts suggest current remediation is effective, but the risk remains until reliable exploit kits are developed.
The five-minute version
Wiz monitored telemetry and honeypot data after publishing two PHP vulnerabilities. They saw a 67% drop in distinct Internet-exposed machines vulnerable to PHP2Shell and a 47.9% reduction in affected organizations. Multiple exploit-kit variants triggered memory exhaustion but never completed the memory-leak stage, and no end-to-end exploit was observed. The evidence is based on real-world telemetry and controlled honeypot experiments, but the authors note that private exploits exist and that differences in PHP builds and worker behavior can affect success.
What they found 3
- Daily number of distinct Internet-exposed machines vulnerable to PHP2Shell decreased by ~67%
“Wiz telemetry has recorded an approximate 67% decrease in the daily number of distinct Internet-exposed machines vulnerable to PHP2Shell over the past few days.”
- No successful end-to-end PHP2Shell exploitation observed in Wiz telemetry
“We have not yet observed successful end-to-end PHP2Shell exploitation in our own telemetry.”
- Current exploit-kit variant exhausts memory but fails to obtain required memory addresses
“The newer variant did consistently exhaust PHP’s memory, but failed to obtain the memory addresses needed to continue.”
What undercuts it the paper’s own results
- Some partners have, however, privately disclosed to us exploits that work against a variety of targets
- Videos demonstrating our successful exploitations are available at php2shell.com.
Stated limits 3
- note that this data shows the overall trend, but does not establish the relative contribution of each remediation strategy; scan coverage and size of observed population can also affect the overall reported numbers over time
- These differences can affect heap layout and memory reuse, potentially preventing the leak from working as expected.
- In our own testing, request timeouts combined with network latency were enough to prevent the chain from completing over an internet connection.
What’s new here 4
- Observed a 67% decrease in vulnerable Internet-exposed machines within days of disclosure.
- Documented that neither legacy nor current exploit-kit variants completed the full PHP2Shell chain in real-world traffic.
- Identified that memory-exhaustion can be achieved but subsequent memory-leak stages consistently fail across deployments.
- Found PHP2Shell-branded tools that use unrelated session-poisoning and LFI techniques.
Artifacts & methods 6
- PHP2Shell exploit kit (legacy chain)primitive
- PHP2Shell exploit kit (current chain)primitive
- Wiz telemetrydataset
- PHP-CGI honeypotsystem
- Roundcube honeypotsystem
- Go port of “Chain A” (session-poisoning tool)primitive