According to reporting by The Hacker News, threat actors have unleashed millions of uncoordinated exploit attempts against newly disclosed unauthenticated remote code execution vulnerabilities dubbed “PHP2Shell” (CVE-2026-109618 and CVE-2026-109619). The flaws, which hold critical CVSS severity ratings of 9.2, exist directly within the underlying PHP engine rather than application-layer software, exposing tens of millions of web services worldwide.
Telemetry from global CDNs, honeypots, and threat research teams reveals a frantic race to recruit exposed infrastructure into existing botnet architectures, most notably a sophisticated Mirai variant codenamed “Potassium.” Yet, despite widespread automated scanning and opportunistic payloads, defenders are observing a notable reality: weaponizing these flaws reliably in production environments is proving far more complex than script-kiddie automation anticipated.
Technical Anatomy of the Exploit Chain
The vulnerability pair impacts PHP branches dating back to PHP 5.4 released in 2012, affecting patched releases prior to versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Because the vulnerability resides within the core PHP interpreter runtime, clean codebases running popular CMS engines like WordPress, Drupal, or custom enterprise applications remain fully exposed if the host binary is vulnerable.
Achieving reliable code execution requires navigating a brittle memory-corruption workflow:
- Worker Recycling & Session Leakage: Analysis of operator tooling such as
aslr_exploit.pyreveals a three-phase sequence targeting Apachemod_php. The attacker forces an active PHP worker process to recycle, subsequently abusing session cookies to leak internal memory pointers. - ASLR Defeat: Address Space Layout Randomization (ASLR) remains the central barrier. To achieve predictable execution without crashing the worker pool, exploit scripts must chain an information disclosure primitive with session upload progress handlers to accurately compute base addresses.
- Payload Execution: Once memory offsets are established, attackers inject code into server-side session stores, attempting to spawn an interactive shell or fetch a secondary stage Linux ELF binary.
“Developing this capability was far from trivial, but it demonstrates that a major barrier to exploiting PHP2Shell on production-configured systems can be overcome.” — Spencer McIntyre, Director of Exploit Development at VulnCheck
In the Wild: The “Potassium” Botnet Infiltration Attempt
While specialized research teams have proven reliable ASLR bypasses in lab conditions, mass exploitation in the wild remains largely broken. Telemetry captured by Sophos, Arctic Wolf, and Previdian shows threat actors attempting to pull down loaders from infrastructure including 92.118.112[.]100 and establishing command-and-control (C2) callbacks to thunder.godofthunder[.]st (resolving to 134.199.154[.]64 over TCP port 50792).
The Potassium payload exhibits several advanced evasion techniques:
- Obfuscated Wire & Configuration: Static configuration tables are encrypted using ChaCha20, while all wire communications are masked under a static single-byte XOR pattern (
0xED). - DNS Misdirection: The binary swaps the two 16-bit halves of resolved
Arecord addresses prior to invokingconnect(), confusing perimeter deep packet inspection (DPI) sensors. - Targeted Disruption: Despite global scanning, the botnet’s objective was identified as launching sustained multi-vector volumetric flood attacks (ICMP, TCP, UDP, and OpenVPN floods) against narrow infrastructure targets in Ukraine.
- Decentralized Fallback: Latent support for Ethereum Name Service (ENS) resolution was discovered inside x86 and ARM builds, designed to bypass traditional registrar and DNS takedowns if activated.
The Security Takeaway
The emergence of PHP2Shell highlights a persistent structural risk in enterprise attack surfaces: engine-level vulnerabilities bypass perimeter assumptions. An enterprise application can pass rigorous SAST/DAST audits, enforce strict input validation, and maintain zero application-level vulnerabilities, yet remain entirely penetrable if the host runtime is vulnerable.
To defend against active exploitation attempts, engineering and security operations teams should prioritize the following actions:
- Runtime Version Upgrades: Immediately upgrade PHP runtimes to supported patched releases (8.5.12, 8.4.27, 8.3.36, or 8.2.35). For legacy systems pinned to deprecated versions (such as PHP 7.x or 8.0/8.1), deploy hardened distribution backports or isolate workloads behind strict reverse proxies.
- Inspect Session Upload Handlers: Evaluate whether
session.upload_progress.enabledis strictly required in production configurations. Disabling or strictly restricting progress monitoring reduces the attack surface leveraged by memory leakage techniques. - Edge WAF & Behavioral Rules: Enforce edge firewall rules that detect anomalous session manipulation, binary payloads in upload parameters, and repeated worker recycling signatures. Filter outbound traffic from web application tiers to prevent web workers from making arbitrary external TCP connections to unverified IP ranges.
- Attack Surface Auditing: Use continuous asset discovery to inventory Internet-facing PHP services across cloud environments and edge hosting providers, ensuring legacy shadow infrastructure is cataloged and retired.
Related Reading & Weekly Links
- The Hacker News: PHP2Shell Exploit Attempts Hit Millions
- Cisco Talos Threat Advisory: PHP2Shell Vulnerability Scanning and Telemetry
- VulnCheck Research: Bypassing ASLR on Production PHP Engines