Thought Leadership
Attacks targeting the PHP2Shell vulnerabilities had previously failed. A honeypot has now provided evidence that attackers can execute code on vulnerable servers. A third vulnerability remains unpatched, with only a workaround available for now.
Administrators who have not yet installed the PHP security update released on October 21, 2026, should no longer delay. For the two vulnerabilities known as PHP2Shell, CVE-2026-109618 and CVE-2026-109619, evidence has emerged for the first time that attackers have successfully executed code on servers they do not control. Until now, only failed attempts had been reported.
The evidence comes from Adel Karimi, who works in detection and response at Perplexity. He operates honeypots, deliberately vulnerable decoy servers designed to attract attackers, and has documented the captured activity on GitHub. The target was an Apache web server running mod_php and PHP 8.4.26.
Memory Disclosure Paves the Way for Code Execution
The attack unfolded in two stages. First, the attackers tricked the server into disclosing portions of its memory, packaged in a cookie response that measured around 800 KB when decoded. They searched this memory dump for a function address, using offsets from a publicly available exploit. That exact address subsequently appeared in the payload used to execute the code.
For Karimi, this confirms genuine code execution rather than a simple crash followed by an unusual process.
However, the findings have limited applicability to other environments. The honeypot was deliberately configured to favor the attacker, with just one mod_php worker. The captured data do not establish whether the exploit would work reliably with multiple workers, different PHP builds, or other applications.
Marcus Hutchins, a security researcher at Expel, has been tracking numerous reports of alleged PHP2Shell compromises. He considers Karimi’s analysis by far the most convincing evidence he has encountered so far.
Rocky Start: Vulnerability Details Leaked Before the Patch
The vulnerabilities had a disorderly disclosure timeline. On October 20, the PHP team announced emergency updates, which were released the following day. However, details had already leaked, including the CVE identifiers and mitigation recommendations that had been shared in advance with some critical infrastructure operators. Initial proof-of-concept exploits also surfaced, but PHP developers said they did not work.
Attacks began accordingly early. Amazon Threat Intelligence detected activity four days before the update was released. Cloudflare, Hadrian, watchTowr, Previdian, and Patchstack also reported attempts, but all classified them as unsuccessful. Dataminr likewise concluded that attackers had so far been scanning systems, identifying potential targets, and trying ineffective exploits. No compromised servers were known at the time.
New Vulnerability Still Has No Patch
The PHP community must also address another remote code execution (RCE) vulnerability: CVE-2026-115560, which remains unpatched. According to the developers, however, exploitation requires an unusual configuration combined with specific application code. As a temporary mitigation, the PHP team recommends setting session.upload_progress.enabled=0. The same configuration change was already recommended as a protective measure before the PHP2Shell patches were released.
The potential attack surface is substantial. According to W3Techs, PHP powers around 70 percent of all websites. VirusTotal estimates that more than 5.1 million PHP hosts are reachable online, with just over 3.8 million exposing at least one open port.
(Editorial Team)
