Two critical vulnerabilities in the PHP core — CVE-2026-109618 and CVE-2026-109619 (CVSS v4.0 9.2) — triggered a wave of scanning and exploitation attempts within hours after they were disclosed on 21 October 2026. The vulnerabilities allow unauthenticated remote code execution through specially crafted HTTP requests and affect all PHP versions prior to 8.2.35, 8.3.36, 8.4.27 and 8.5.12. According to several independent research groups — Sophos, Arctic Wolf and Hunt.io — none of the observed attempts has resulted in a confirmed compromise. We have already written about the technical details of these vulnerabilities and protection measures; this article focuses on analysing real attacker activity and the reasons why exploitation has turned out to be more difficult than expected.
The nature of the vulnerabilities and the scale of the attack surface
According to the CERT/CC advisory (VU#763488), CVE-2026-109618 is a memory corruption vulnerability in PHP’s out-of-memory (OOM) handling mechanism: under certain conditions, partially initialised request data can be accessed during cleanup. CVE-2026-109619 is a use-after-free vulnerability in which stale global state belonging to one request is reused by a subsequent request handled by the same worker process.
The vulnerable code has been present in PHP since version 5.4 (2012), which means the issue affects the PHP engine itself, not a specific application. Any site running WordPress, Drupal or Joomla with clean application code remains vulnerable if PHP is not updated. The affected configurations include PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. According to CERT/CC, Apache mod_php poses the greatest risk because exploitation can occur before application code is executed.
According to Censys estimates, as of 23 October 2026 more than 34.4 million PHP services remained potentially vulnerable out of over 56.6 million web properties using PHP. Organisations on PHP 7.4, 8.0 or 8.1 do not receive official security updates from the PHP Project and require distribution backports or migration to a supported branch.
Attacker activity: a lot of noise, zero results
Large-scale scanning and exploitation attempts began within 45 minutes of the public disclosure of the vulnerabilities. According to Arctic Wolf, observed activity ranged from basic checks for vulnerable behaviour in PHP’s session upload progress tracking mechanism to attempts to confirm OS command execution.
A fundamentally important fact: Sophos initially reported successful PHP2Shell exploitation among its customers, but later revised this assessment, noting that telemetry showed only scanning and failed attempts with no evidence of successful compromise. Hunt.io independently confirmed this conclusion: the only identified mass exploitation operator made ten passes against 123 servers and did not obtain a single shell. Wordfence, Previdian, Beelzebub and Dataminr are seeing the same picture.
The main reason for attackers’ failures is the need to bypass ASLR (Address Space Layout Randomization), a mechanism that randomises the address space layout and makes code locations in memory unpredictable. VulnCheck developed a method that chains the two vulnerabilities together to bypass ASLR on x86-64 systems with recommended production PHP settings, but emphasised that building such an exploit is “far from trivial.” This explains the gap between mass scanning and the absence of successful attacks.
The Potassium botnet and attack infrastructure
The observed exploitation traffic is associated with Potassium — a Mirai-based botnet variant first detected by the Synthient platform in March 2026. The link has been established at the infrastructure and malware sample level by three independent research groups (Sophos, Arctic Wolf, Hunt.io), but the specific threat actor responsible has not been identified. It is important to stress: the evidence ties PHP2Shell requests to Potassium infrastructure, but does not confirm that the associated samples were downloaded and executed via these vulnerabilities.
According to Sophos, the Potassium sample establishes a TCP connection to the C2 server 134.199.154[.]64, sends an HTTP request and waits to receive a Linux ELF binary in response. The botnet supports 24 commands for launching DDoS attacks over ICMP, TCP, UDP and OpenVPN. Notable technical features include use of ChaCha20 to encrypt the static configuration table (a first for Mirai variants), a DNS redirection scheme that swaps the 16-bit halves of each A record, and dormant but built-in support for resolving C2 infrastructure via Ethereum Name Service (ENS).
Separately, SOCRadar discovered a set of PHP2Shell exploitation tools on an attacker’s open server (206.188.197[.]105:9999), including a script named aslr_exploit.py — an exploit for PHP 8.4.26 on Apache mod_php that works in three stages: restarting a PHP worker, leaking memory addresses via the session cookie to bypass ASLR, and abusing the session upload progress tracking mechanism to execute a command.
Indicators of compromise
Key IOCs from the research:
- Attack source IP addresses: 85.11.167[.]243, 217.60.242[.]76, 45.198.224[.]169
- Download infrastructure: 92.118.112[.]100, 206.188.197[.]105
- C2 server: 134.199.154[.]64 (TCP port 50792)
- Domains: thunder[.]godofthunder[.]st, hackattackkaboom[.]botlesscucks[.]st
- Sample hashes: 0c5486f06620e26e316f4b33f318b0d646d5e1133789331aa2fed012360d1486, e2529d4afa39ae4db2eb05d5176317c906289abf09660c75bdeec43e54c55aa3
Practical detection of exploitation attempts
According to Hunt.io and Arctic Wolf, distinguishing between scanning attempts and actual compromise requires correlating several signals:
- A User-Agent containing strings such as
php2shell-scan/109618orphp2shell-109618 - Multipart POST requests with a
PHP_SESSION_UPLOAD_PROGRESSfield and an abnormally large body - Spikes in “Allowed memory size exhausted” errors in PHP-FPM logs
- Subsequent activity: process creation, changes in the web server’s document root, outbound network connections to the listed C2 addresses
The presence of the first three indicators points to an exploitation attempt; the fourth indicates a possible compromise that requires immediate investigation.
Recommendations
- Immediately update PHP to versions 8.2.35, 8.3.36, 8.4.27 or 8.5.12, as recommended by CERT/CC
- Organisations on PHP 8.1 and below do not receive updates from the PHP Project — you must migrate to a supported branch or apply a distribution backport
- Check your web server logs for the listed IOCs and exploitation patterns
- Block network connections to the specified C2 addresses and domains at the perimeter
- For Apache mod_php configurations, consider a temporary switch to PHP-FPM, which provides additional process isolation
The current PHP2Shell situation is reminiscent of the early days of Log4Shell: the vulnerable code has existed for more than ten years, affects the engine rather than the application, and lacks patches for legacy branches. The absence of confirmed compromises so far is the result of the technical difficulty of bypassing ASLR, not of vulnerable systems being secure. VulnCheck has already demonstrated that this barrier can be overcome. The priority for every organisation using PHP is to update to a fixed version before reliable exploits become available to a broader set of attackers.
