~/home/news/mirai-botnet-hijacks-php2shell-2026-10-30
newsFriday, October 30, 20268 min read👁 2 views

Mirai Botnet Hijacks PHP2Shell Exploits; New ASLR Bypass Threat Emerges

Two critical PHP engine bugs (CVE-2026-109618/109619) are being weaponised by Mirai-derived botnets. A novel ASLR-bypass chain now enables unauthenticated RCE even when PHP error display is disabled, though no live shell access has been confirmed yet.

PHPMiraiASLRRCE

Overview/Introduction

In the span of a week, the web-application ecosystem has been shaken by a confluence of events surrounding the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619). After the PHP project rushed emergency patches on 21 October 2026, threat actors quickly pivoted to exploit the flaws for large-scale malware distribution. Most notably, operators of a Mirai-derived botnet-now dubbed Potassium-have begun incorporating the bugs into their infection chain, while a separate research group has released an ASLR-bypass exploit that sells for a premium on underground markets. Although no confirmed in-the-wild shell sessions have been observed, the activity signals a rapid escalation from proof-of-concept to active weaponisation.

Technical Details

The two CVEs share a common root cause: improper handling of crafted zend_string structures during zend_parse_parameters() processing. When a specially-crafted request is sent to a vulnerable PHP interpreter running under Apache’s mod_php SAPI, the engine dereferences a controlled pointer, leading to arbitrary memory write and ultimately unauthenticated remote code execution (RCE). Both bugs received a CVSS v4.0 score of 9.2 (critical).

  • CVE-2026-109618: Allows out-of-bounds write via malformed zend_string length field.
  • CVE-2026-109619: Triggers use-after-free in the same parsing routine, enabling code injection.

Patch versions released on 21 Oct 2026:

  • PHP 8.2.35
  • PHP 8.3.36
  • PHP 8.4.27
  • PHP 8.5.12

All four versions address the memory-corruption paths and include a hardening flag that disables the vulnerable code paths when display_errors is off. However, the newly disclosed exploit chain circumvents this mitigation by chaining a heap-spray with a return-oriented programming (ROP) payload that bypasses Address Space Layout Randomization (ASLR) on x86-64 systems. The chain works as follows:

  1. Send a crafted HTTP request that triggers the out-of-bounds write (CVE-109618).
  2. Leverage the resulting memory corruption to place a ROP gadget table in a predictable location.
  3. Use a second request (CVE-109619) to pivot execution to the gadget chain, which disables ASLR for the current process.
  4. Execute a final system() call that spawns a shell, even when display_errors is disabled.

The exploit has been packaged as a .py script and is being sold to threat-intel customers for roughly $12 k per license. The vendor claims the tool works reliably against all four patched PHP versions when the server runs with default mod_php configurations.

Impact Analysis

The affected attack surface is remarkably broad:

  • Any public-facing web server running the vulnerable PHP versions, especially those using Apache’s mod_php SAPI.
  • Enterprise, government, education, and healthcare sites that rely on legacy PHP stacks and have not yet applied the emergency patches.
  • Cloud-hosted SaaS platforms that bundle PHP in container images, where the vulnerable interpreter may be hidden behind layers of abstraction.

Because the vulnerability is exploitable without authentication or prior knowledge of the target’s codebase, a successful compromise can lead to:

  • Installation of ransomware-capable payloads (e.g., the Potassium botnet’s loader).
  • Full control of the underlying host, enabling lateral movement to internal services.
  • Use of the compromised host as a stepping stone for large-scale DDoS attacks, as Mirai-style bots are designed to.

While the CVSS rating is high, the current lack of confirmed, persistent shell sessions keeps the overall severity at high rather than critical.

Timeline of Events

  • 17 Oct 2026 - Amazon Web Services detects the first exploitation attempts against PHP2Shell.
  • 20 Oct 2026 - Security researchers (Wiz, OpenAI, Calif) publicise the vulnerabilities and request CVE identifiers.
  • 21 Oct 2026 - PHP releases emergency patches (8.2.35, 8.3.36, 8.4.27, 8.5.12) a day earlier than planned.
  • 21-22 Oct 2026 - Multiple European government, school, and hospital websites go offline as administrators apply patches.
  • 23 Oct 2026 - Sophos reports a blocked attempt to install a Mirai-derived variant (Potassium) via PHP2Shell.
  • 24 Oct 2026 - Hunt.io attributes PHP2Shell traffic to an established Mirai-style botnet active since May 2026.
  • 26 Oct 2026 - A security firm releases an ASLR-bypass exploit chain for sale; samples of custom tooling appear on a public attacker server.
  • 28 Oct 2026 - Arctic Wolf links Potassium binaries to the same infrastructure hosting PHP2Shell payloads, though no execution logs are observed.
  • 30 Oct 2026** (today)** - No confirmed in-the-wild shell access, but threat-intel feeds indicate active scanning and exploit development.

Mitigation/Recommendations

Given the speed of weaponisation, organisations should treat PHP2Shell as an immediate priority. Recommended actions:

  1. Patch immediately. Upgrade all PHP installations to the patched releases (8.2.35, 8.3.36, 8.4.27, 8.5.12) or later. Verify the version with php -v on each host.
  2. Disable mod_php where possible. Consider switching to PHP-FPM with a separate process pool; this limits the attack surface and eases containment.
  3. Enforce strict request size limits. The exploit relies on oversized payloads; configuring LimitRequestBody in Apache to a few kilobytes can mitigate early stages.
  4. Enable Web Application Firewalls (WAF). Deploy signature-based rules that detect the specific request patterns used by the ASLR-bypass chain (e.g., unusual Content-Length values combined with crafted GET parameters).
  5. Monitor for anomalous process creation. Watch for unexpected php processes spawning sh or bash without a parent web service.
  6. Network segmentation. Isolate web servers from critical internal systems; use outbound filtering to block connections to known C2 domains associated with Potassium.
  7. Incident response readiness. Prepare a rapid rollback plan and evidence-preservation workflow in case a breach is detected.

Real-World Impact

Even without confirmed shell sessions, the mere presence of an active exploitation attempt forces organisations to make hard choices:

  • Many European public-sector sites voluntarily went dark on 21 Oct, sacrificing availability to protect data integrity.
  • Enterprises that rely on legacy PHP applications (e.g., internal dashboards, legacy e-commerce platforms) risk being forced offline while patches are applied, potentially disrupting business operations.
  • The potential for ransomware deployment via the Potassium loader raises the stakes for data-centric organisations such as hospitals, where downtime directly impacts patient care.
  • Cloud providers that host multi-tenant PHP environments may see increased demand for managed, patched runtime images, shifting market dynamics toward container-native PHP-FPM offerings.

Expert Opinion

From a strategic standpoint, the rapid co-optation of PHP2Shell by Mirai operators illustrates a broader trend: botnet-as-a-service ecosystems are increasingly leveraging zero-day-ish web-application flaws to bootstrap massive infection fleets. The ASLR-bypass chain is particularly concerning because it demonstrates that even mitigations traditionally considered robust (like disabling error display) can be sidestepped with a sophisticated ROP payload.

What this means for the industry is two-fold:

  1. Patch velocity must improve. The fact that PHP accelerated its patch schedule by a full day after CVE identifiers leaked shows the pressure, but many organisations still lag. Automated, continuous-integration pipelines that pull in upstream security patches are no longer optional.
  2. Defense-in-depth for web stacks is mandatory. Relying solely on language-level mitigations (e.g., display_errors=Off) is insufficient. WAFs, runtime sandboxing, and process isolation (PHP-FPM) should be standard practice, especially for high-value targets.

Finally, the commercialisation of the ASLR-bypass exploit signals a monetisation model that could lower the barrier for less-skillful actors. Security teams should therefore treat the existence of a for-sale exploit as a credible threat, even if active exploitation has not yet been observed in the wild.