PHP2Shell Exploit Attempts Hit Millions as Attackers Try to Deploy Mirai Malware

Threat actors have been attempting to exploit the newly disclosed PHP2Shell vulnerabilities to deploy a Mirai botnet variant called Potassium. The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, have CVSS scores of 9.2 and can result in unauthenticated remote code execution via specially crafted HTTP requests. These vulnerabilities have been patched in PHP versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35.

Cloudflare reported observing tens of thousands of exploitation attempts just 45 minutes after the vulnerabilities were publicly announced, with the number climbing to hundreds of thousands within two hours and reaching millions by early October 22, 2026. Despite the massive volume of attempts, researchers have not yet observed any successful remote code execution.

Potassium Botnet Details

The attacks originate from three IP addresses: 85.11.167[.]243, 217.60.242[.]76, and 45.198.224[.]169. These sources contact 92.118.112[.]100 to retrieve a loader responsible for deploying the Potassium botnet variant. The botnet issues a DNS query for thunder.godofthunder[.]st, resolves it to 134.199.154[.]64, and establishes a command-and-control channel on TCP port 50792.

Potassium, first flagged by Synthient in March 2026, is an updated and significantly expanded version of the Mirai botnet. Nokia Deepfield researchers noted it uses "ChaCha20 for the static config table" and employs a "DNS misdirection scheme that swaps the two 16-bit halves of every resolved A record before connect()." The botnet supports 24 commands to facilitate flood attacks over ICMP, TCP, UDP, and OpenVPN protocols.

The end goal is to launch sustained volumetric flood attacks against two adjacent hosts within a Ukrainian network: 45.88.138[.]0 and 45.88.138[.]44. Despite these efforts, the lack of successful attacks suggests threat actors are "struggling" to develop reliable exploits for the PHP2Shell vulnerabilities.

Exploit Tooling Discovered

SOCRadar discovered PHP2Shell exploit tooling for PHP 8.4.26 on an exposed server (206.188.197[.]105:9999), along with three screening scripts that check websites for preconditions the exploit requires. These scripts targeted about 20 websites across Canada, China, Finland, France, Poland, the U.K., and the U.S.

The central exploit file, aslr_exploit.py, is labeled a "one-click" PHP2Shell exploit that works over HTTP in three steps: recycling the target's PHP worker, leaking memory addresses through session cookies to defeat ASLR, and abusing PHP's session upload progress handling to run shell commands. ASLR (Address Space Layout Randomization) is a cybersecurity mechanism that randomizes memory locations to make attacks harder.

The toolset is part of a broader operation targeting cryptocurrency and Web3 infrastructure. The same server has been flagged by Hunt.io, which reported the threat actor has targeted 123 servers across cloud, shared-hosting and ISP networks. In total, 10 open directories have been found hosting PHP2Shell-related tooling.

Overcoming ASLR Protections

VulnCheck researchers have developed a novel technique to achieve remote code execution on ASLR-enabled x86-64 systems with PHP's recommended production configuration. "One of the biggest obstacles has been address space layout randomization (ASLR), a protection designed to make memory corruption vulnerabilities much harder to exploit," said Spencer McIntyre, director of exploit development at VulnCheck.

The technique chains the two PHP2Shell vulnerabilities together, using a memory leak to bypass ASLR. "We haven't identified another public or commercial exploit that achieves this under the same conditions," McIntyre noted. "Developing this capability was far from trivial, but it demonstrates that a major barrier to exploiting PHP2Shell on production-configured systems can be overcome."

The consequences of successful exploitation could be severe, allowing attackers to execute code with web application permissions, potentially gaining access to API keys, database connections, and other internal services. "Access to a vulnerable web application could provide a foothold into other parts of an organization's infrastructure," McIntyre warned.