Fake PoCs and a failed webshell attempt

The public exploit ecosystem

The public exploit ecosystem around PHP2Shell is noisy. WatchTowr said the circulating PoCs it tested did not achieve remote code execution: they failed outright, measured timing differences or crashed the target. JFrog found repositories labelled as PoCs that were pranks, including one that changed the victim’s desktop wallpaper. VulnCheck reported at least one failed attempt to deploy a webshell from a Chinese IP.

Bitdefender, meanwhile, said it had not observed exploitation itself and explicitly flagged a reported AWS observation from 17 October as something it had not independently confirmed.

Why a failed PoC is not reassurance

A failed public PoC does not mean the vulnerability is not exploitable. It means that particular code did not work against that particular target. The PHP advisories describe a real memory-corruption path, Wiz demonstrated laboratory exploitation, and multiple vendors observed attempts. The correct conclusion is narrower: not every file labelled “PHP2Shell exploit” is functional, and not every claimed compromise is verified.

This is also a security risk for defenders. Downloading and running unknown “PoC” code from a public repository can execute malware on the analyst’s machine. The prank repositories are a mild version of the problem. Treat exploit code as untrusted code, especially during a high-attention event when fake repositories are easy to rank and share.

What to record

For an incident log, keep four categories separate: a PoC exists; a PoC was tested in a lab; an attempt was observed against a target; a compromise was confirmed. PHP2Shell has public evidence for the first three, in different degrees. The fourth has not been publicly established for a specific production site in the sources reviewed here as of 22 October 2026 (UTC).