Despite the claims, there is still no public evidence of a generic exploit for PHP2Shell.
An engineer at HubSpot compiled — with the help of AI and, as he concedes, without full verification — a concise timeline. It offers a glimpse into the sequence of announcements… and retractations.
A Disclosure Not as Coordinated as It Seemed
Before we get there, there was the coordinated disclosure procedure for the two vulnerabilities. And the mishandling of the embargo that came with it. Chainguard did indeed break it. About ten hours before the agreed deadline, it released patched builds of its Wolfi distribution. Its boss frames this choice as a reaction to reports of active exploitation on the coordination channels. He adds that the decision was reinforced by the “ease” with which the company managed to develop its own PoC.
A Crowds of PoCs… “Lab-Based”
VulnCheck is among cybersecurity firms that claimed a “lab-based” PoC. It initially said it was functional against PHP 8.4.26 (mod_php) on x86-64 with ASLR enabled and display_errors = off. Since then, its claimed coverage has widened to most unpatched versions across branches 8.2 to 8.5, and, for some, to ARM architectures.
Trail of Bits also progressed gradually. Until it asserted having a “production” exploit, especially since it worked in multiworker mode with the default php.ini configuration. It presented a demonstration against MediaWiki, WordPress, Symfony, phpBB, and Laravel.
Announcements of Compromises Followed by Retractions
In an alert related to PHP2Shell, India’s CERT notes that “multiple reports confirm widespread exploitation.” It, however, does not source them.
Sophos went so far as to claim proof of compromise, but retracted a few hours later. The same happened at Palo Alto Networks. Its Unit 42 team had reported an attack against a European government agency that resulted in the theft of password hashes and MFA secrets “within two hours after exploitation.” It ultimately recanted: the attack occurred in the context of a vulnerable PHP application, but it is not certain that PHP2Shell was the initial access vector…
At Perplexity, Limited Evidence of Exploitation Outside the Lab
The most credible trace of a successful PHP2Shell exploitation “in the wild” may come from Perplexity’s director of detection and response.
The individual observed, on a honeypot network, a four-step exploitation chain culminating in arbitrary code execution. It mirrors a family of public PoCs.
The first request exhausts memory and leaves the heap in an invalid state. The second forces the return of an abnormally large cookie that exposes part of the process’s memory. The attacker can then map the layout and compute the offsets needed to bypass ASLR.
The third request stabilizes the PHP heap into a predictable state so that the structure to be corrupted in the final step lands exactly at the calculated location. The content of the final request is dynamic. In addition to the shell command to inject, it incorporates the recalculated memory addresses based on the extracted pointers. The worker diverts its instruction flow and spawns a child process that executes the payload.
The memory corruption crashes the worker before any application code can run. However, the eBPF audit allows logging the launch of shell processes. Logs that can be correlated to the request via packet captures.
The honeypot configuration was favorable to attackers, notes Perplexity’s director of detection and response. It was not representative of typical deployments (PHP 8.24.6 instances running via mod_php in monoworker mode, memory_limit = 128M).
On Monday, CISA nonetheless added PHP2Shell to its KEV (Known Exploited Vulnerabilities) catalog.
