Threat actors are attempting to exploit the recently disclosed PHP2Shell vulnerabilities to infect vulnerable systems with a Mirai-based botnet variant known as Potassium. However, security researchers report that the attacks have so far failed, suggesting that weaponizing the flaws against real-world targets may be more difficult than initially anticipated.
The vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, carry CVSS scores of 9.2 and could allow unauthenticated remote code execution (RCE) through specially crafted HTTP requests.
PHP has addressed the flaws in versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
According to Sophos, the malware sample observed during the exploitation attempts is an updated and significantly expanded version of a Mirai-derived botnet first identified in early 2026. The sample includes downloader capabilities and functionality designed to disrupt network availability.
Potassium Botnet Uses PHP2Shell Exploitation Attempts to Deploy Malware
Analysis by Sophos found that the Potassium sample retrieves an encrypted, hard-coded command-and-control (C2) address before establishing a TCP connection to 134.199.154[.]64 and sending an HTTP request.
The malware checks whether the server returns an HTTP 200 status code and verifies that the downloaded payload begins with the ELF magic bytes 7F 45 4C 46. This indicates that it expects a Linux executable as a follow-on payload.
The sample also includes a resolver capable of handling IPv4 addresses and hostnames. Its fallback mechanisms use public DNS resolvers, including:
8.8.8.81.1.1.11.0.0.1
Like other Mirai-based malware, Potassium can launch distributed denial-of-service (DDoS) attacks against targeted systems.
Researchers identified three IP addresses associated with the observed attack attempts:
85.11.167[.]243217.60.242[.]7645.198.224[.]169
The systems contacted 92.118.112[.]100 to retrieve a loader responsible for deploying the botnet.
Further analysis in a network-isolated sandbox revealed that the malware queries thunder.godofthunder[.]st, resolves the domain to 134.199.154[.]64, and establishes a C2 connection over TCP port 50792.
The campaign’s apparent objective is to conduct sustained volumetric DDoS attacks against two adjacent hosts within the same Ukrainian network:
45.88.138[.]045.88.138[.]44
Despite these activities, Sophos reported no confirmed successful exploitation of PHP2Shell in the observed attacks, indicating that threat actors may still be struggling to develop reliable exploits.
Potassium Is an Expanded Mirai-Based Botnet
Potassium was first identified by botnet-tracking platform Synthient in March 2026.
In a subsequent analysis, Nokia Deepfield researchers described the malware as a Mirai fork with several unusual technical features.
These include ChaCha20 encryption for its static configuration table, a single static byte (0xED) used for network traffic, and a named reverse-shell protocol called SHELL / SHOUT that operates on the same communication channel as attack commands.
The malware also uses a DNS manipulation technique that swaps the two 16-bit halves of a resolved IPv4 address before attempting to connect.
Arctic Wolf researchers, who investigated another PHP2Shell exploitation attempt involving the same botnet, found that Potassium supports 24 commands for launching flood attacks over ICMP, TCP, UDP, and OpenVPN-related traffic.
Both ARM and x86 builds also contain configuration options for resolving C2 infrastructure through the Ethereum Name Service (ENS).
However, Arctic Wolf found that ENS resolution was disabled in both analyzed samples.
If enabled in future versions, the capability could make infrastructure takedowns more difficult by reducing the malware’s dependence on conventional domain registrars and DNS providers. Defenders might then need to block ENS names, associated RPC infrastructure, and resolved C2 addresses.
Attackers Discover PHP2Shell Exploit Tools on Exposed Server
Separately, cybersecurity firm SOCRadar discovered PHP2Shell exploit tooling hosted on an attacker-controlled server at 206.188.197[.]105:9999.
The server contained an exploit targeting PHP 8.4.26, along with three scripts designed to identify websites that meet the technical requirements for exploiting the vulnerabilities.
According to SOCRadar, the scripts examined approximately 20 public websites across Canada, China, Finland, France, Poland, the United Kingdom, and the United States.
The central tool, aslr_exploit.py, was described by its operator as a one-click PHP2Shell exploit for PHP 8.4.26 running under Apache’s mod_php.
The exploit operates through ordinary HTTP requests and follows three broad stages:
- Recycles the target’s PHP worker process.
- Leaks memory addresses through a session cookie to bypass Address Space Layout Randomization (ASLR).
- Abuses PHP session upload-progress handling to execute a shell command.
ASLR is a security mechanism that randomizes memory locations used by programs and system components. This makes it harder for attackers to predict where executable code resides in memory and is commonly used to mitigate memory-corruption attacks.
SOCRadar also identified three supporting scripts:
php2shell_fp.py— Collects PHP version and server configuration information from approximately 20 websites.deep_probe.py— Examines 11 websites for visible errors, exposedphpinfopages, file inclusion issues, and session injection behavior to determine whether exploit prerequisites are present.wp_attack.py— Targets five WordPress websites for user and plugin enumeration.
As of October 22, 2026, researchers had found no evidence of successful shell access on any of the screened websites. The findings suggest that the targets did not meet the exploit’s required conditions.
Broader Reconnaissance Operation Targets Web and Web3 Infrastructure
SOCRadar assessed that the exploit tooling was part of a broader operation involving reconnaissance, automated testing, and attempts to identify exposed credentials and services.
The activity reportedly includes extracting API keys and backend URLs from client-side JavaScript, systematically scanning web and API endpoints for unauthenticated access, and routing traffic through rotating proxies to evade rate limits and security controls.
Related files on the same server also indicated the use of web-archive reconnaissance and automated CAPTCHA-solving tools.
Taken together, SOCRadar said the evidence points to a financially motivated threat actor with an apparent focus on cryptocurrency and Web3-related targets.
Threat intelligence company Hunt.io also identified the exploitation server at 206.188.197[.]105.
According to Hunt.io, the operator targeted 123 servers across cloud platforms, shared-hosting environments, and internet service provider networks. Approximately 57 of those servers were running PHP, including many systems using unsupported PHP 5.x through 7.x versions.
Ten servers rejected the requests outright, including three of five systems protected by Cloudflare. Hunt.io reported that none of the targeted servers was successfully exploited.
Researchers also identified PHP2Shell-related tools in 10 groups of exposed directories hosted across the following IP addresses:
206.188.197[.]105102.210.149[.]166122.10.110[.]72122.10.17[.]4958.221.60[.]160:800041.223.30[.]7157.230.117[.]70104.219.251[.]31107.150.31[.]151217.160.132[.]8247.100.125[.]10854.169.109[.]7139.162.165[.]136
Researchers Develop a Technique to Bypass ASLR
Although most observed exploitation attempts have not resulted in confirmed compromise, researchers have demonstrated that PHP2Shell can be exploited under more restrictive conditions.
Spencer McIntyre, director of exploit development at VulnCheck, told The Hacker News that ASLR had been one of the primary obstacles preventing reliable exploitation.
VulnCheck developed a technique that chains the two vulnerabilities together, using a memory leak to bypass ASLR and achieve remote code execution on x86-64 systems running PHP with its recommended production error-display configuration.
The company said it had not identified another public or commercial exploit capable of achieving RCE under the same conditions.
The research demonstrates that, although developing a reliable exploit is challenging, the security barriers protecting production-configured PHP systems can be overcome.
Successful exploitation could allow an attacker to execute commands with the privileges of the vulnerable web application. Depending on the application’s permissions and configuration, this could expose API keys, database credentials, and connections to internal services.
McIntyre warned that attackers do not necessarily need administrator or root privileges to cause significant damage. Access to a vulnerable web application could provide an initial foothold for moving deeper into an organization’s infrastructure.
Widespread PHP2Shell Scanning Observed Across the Internet
The Potassium campaign is part of a broader wave of scanning and exploitation attempts targeting the PHP2Shell vulnerabilities.
Researchers have observed activity from multiple IP addresses, including a China-based source reportedly attempting to deploy a web shell through a server-side session file.
Cloudflare reported detecting tens of thousands of exploitation attempts within 45 minutes of the vulnerabilities being publicly disclosed. The volume climbed to hundreds of thousands within two hours and reached millions by early October 22, 2026.
Cisco Talos said much of the activity consisted of scanning and uncoordinated attempts to deliver different payloads.
This pattern is common after a vulnerability becomes public: scanning systems and adapting proof-of-concept code generally requires less effort than developing a reliable exploit that works against an attacker’s intended targets.
Previdian’s telemetry recorded hundreds of attempts targeting CVE-2026-109618 from dozens of IP addresses, with fewer attempts observed against CVE-2026-109619.
The first exploitation event targeting CVE-2026-109618 in its telemetry was recorded on October 21, 2026, at 1:05 p.m. UTC.
Despite the volume of activity, Previdian reported no confirmed remote code execution or dropped PHP files in its honeypots at the time of its analysis.
The assessment was echoed by Beelzebub, Dataminr, and Wordfence. Observed activity included scanning, fingerprinting, attempts to verify command execution, credential and environment-variable theft, persistence installation, and second-stage payload retrieval.
Wordfence identified the following IP addresses among those attempting to exploit the vulnerabilities:
87.121.84[.]174181.215.186[.]252185.196.220[.]132185.161.210[.]29152.233.51[.]6945.134.225[.]16107.189.14[.]87193.47.62[.]242409:40d2:204e:4be:2a1f:f9c9:a055:e00b103.147.220[.]17
Government and Public-Sector Websites Taken Offline as a Precaution
The severity of PHP2Shell has prompted some government, educational, and healthcare organizations to take websites and digital services offline while investigating exposure and applying security measures.
The United Kingdom government confirmed that 32 digital services were unavailable and another four were partially unavailable, largely because of precautionary shutdowns and mitigation efforts.
The UK’s National Cyber Security Centre (NCSC) also issued approximately 50,000 warnings to businesses and other organizations.
Researchers at the Sysdig Threat Research Team noted that the vulnerable code dates back to PHP 5.4, released in 2012.
Because the flaws exist within the PHP engine rather than in individual applications, websites running WordPress, Drupal, Joomla, or other content management systems may remain vulnerable even when their application code is otherwise secure.
This distinction is particularly important for website owners who assume that keeping their CMS, themes, and plugins updated is sufficient to protect their installations.
Millions of PHP Services May Remain Vulnerable
The long history of the affected code and the absence of fixes for some legacy PHP versions could make PHP2Shell a persistent security problem, potentially resembling the prolonged impact of Log4Shell.
According to estimates from Google-owned VirusTotal, approximately 272,000 hosts run supported PHP branches from versions 8.2 through 8.5.
Organizations running PHP 7.4, 8.0, or 8.1 should migrate to a supported PHP branch or apply an appropriate security backport provided by their operating system or distribution vendor.
Meanwhile, attack surface management platform Censys reported detecting more than 3.08 million hosts and 56.6 million web properties running PHP. As of October 23, 2026, the platform assessed more than 34.4 million PHP services as potentially vulnerable.
Dataminr warned that widespread exposure could persist even after organizations begin applying patches, because many applications depend on web servers and software components that must be updated by their respective vendors.
How Organizations Can Reduce PHP2Shell Risk
Organizations running PHP-based websites should treat PHP2Shell as a high-priority security issue and take steps to identify and mitigate potential exposure.
Recommended measures include:
- Upgrade PHP immediately: Install a patched release appropriate for the deployed PHP branch: 8.5.12, 8.4.27, 8.3.36, or 8.2.35, as applicable to the reported vulnerabilities.
- Review legacy PHP deployments: Identify unsupported versions and migrate to a supported branch or apply a verified vendor-provided security backport.
- Audit WordPress and other CMS environments: Check the underlying PHP runtime, hosting configuration, and server software in addition to updating CMS core files, themes, and plugins.
- Inspect logs for suspicious requests: Look for unusual HTTP requests, session-related activity, unexpected command execution, and connections to suspicious external hosts.
- Investigate potential compromise: Check for unauthorized PHP files, unexpected processes, suspicious outbound connections, and signs of credential theft or persistence.
- Restrict unnecessary outbound traffic: Where operationally feasible, limit server connections to untrusted destinations and monitor unusual DNS and TCP activity.
- Review exposed credentials: If compromise is suspected, rotate affected API keys, database passwords, and other secrets accessible to the web application.
- Continue monitoring: Watch for new exploit variants, botnet payloads, and updated indicators of compromise as researchers release additional findings.
Conclusion
The emerging PHP2Shell campaigns illustrate the difference between widespread exploitation attempts and successful compromise. Although attackers are actively scanning for vulnerable PHP installations and experimenting with exploit tooling, current reporting indicates that many observed attempts have failed to achieve remote code execution.
However, VulnCheck’s research shows that reliable exploitation is technically possible under production-like conditions. The Potassium botnet’s use of PHP2Shell as an attempted deployment vector further highlights the potential consequences if attackers overcome the remaining barriers.
With millions of PHP services potentially exposed and legacy installations likely to remain in use, organizations should prioritize patching, verify their actual exposure, and monitor systems for signs of compromise rather than relying on the current lack of confirmed successful attacks.
