Talk to an expert
PricingNewsTalk to an expert
Back to Newsroom
Threat Intel

PHP2Shell: Millions of Exploit Attempts, No Confirmed Breaches Yet. Patch Before That Changes

Two critical PHP engine flaws are under mass attack, with Mirai botnet payloads in tow. No compromise is confirmed yet, but an ASLR bypass has been shown and tens of millions of servers are exposed.

4T4Tify Team4Tify
Oct 23, 2026·6 min read
PHP2Shell: Millions of Exploit Attempts, No Confirmed Breaches Yet. Patch Before That Changes

PHP2Shell: Millions of Exploit Attempts, No Confirmed Breaches Yet — Patch Before That Changes

Two critical flaws in the PHP engine, collectively nicknamed PHP2Shell, are drawing one of the fastest-growing waves of internet-wide exploitation attempts of the year. Attackers are already trying to turn vulnerable servers into nodes of a Mirai-derived botnet. The good news so far: none of the major sensors tracking the campaign has confirmed a successful compromise. The bad news: a working bypass for the main obstacle attackers face has now been demonstrated, and the pool of exposed servers is enormous.

What happened

CVE-2026-109618 and CVE-2026-109619 (CVSS 9.2) can be chained to achieve unauthenticated remote code execution through crafted HTTP requests. Fixes shipped in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The vulnerable code reaches back to PHP 5.4, and because the bug lives in the engine itself, a WordPress, Drupal or Joomla site with perfectly clean application code is still exposed.

Within the first hour of disclosure, edge networks were logging tens of thousands of exploit attempts; within two hours, hundreds of thousands; by October 22 the count was in the millions. The activity observed so far falls into three buckets:

  • Botnet recruitment. Several attack sources try to pull a loader that installs Potassium, an expanded Mirai fork first spotted in March 2026. It encrypts its configuration with ChaCha20, carries a reverse-shell channel alongside its DDoS commands (24 flood types over ICMP, TCP, UDP and OpenVPN), and ships a dormant option to resolve its command-and-control through the Ethereum Name Service, a feature that would make takedowns harder if switched on.
  • Targeted tooling. An exposed attacker server held a "one-click" exploit for PHP 8.4.26 under Apache mod_php, plus scripts that fingerprint sites for the exploit's preconditions and enumerate WordPress users and plugins. The wider toolkit (scraping API keys from client-side JavaScript, sweeping unauthenticated API routes, rotating proxies, CAPTCHA solving) points to a financially motivated actor focused on crypto and Web3 targets. Around 123 servers were probed; none was compromised.
  • Opportunistic noise. Most of the rest is scanning, fingerprinting and uncoordinated attempts to confirm command execution, read secrets from environment variables, plant web shells via server-side session files, and fetch second-stage payloads.

Why it matters

The reason nobody has a confirmed win yet is ASLR: reliably defeating memory randomization on a production-configured server is hard. That barrier is now weaker. Exploit developers have demonstrated a technique that chains the two bugs, uses a memory leak to bypass ASLR, and gets code execution on x86-64 systems running PHP's recommended production settings. That exploit is not public, but it proves the hard part can be done, and history says capable actors will follow.

The exposure is huge. Internet-scanning estimates put the number of vulnerable PHP services in the tens of millions. Only about a quarter of the hosts that reveal their PHP version run a branch that receives fixes at all; hundreds of thousands still advertise end-of-life 7.x and 5.x builds. As with Log4Shell, expect a long tail: embedded and vendor-managed PHP stacks will stay vulnerable long after first-party apps are patched. Several government, school and hospital sites in Asia, Europe and North America have already been pulled offline as a precaution.

A successful hit runs code with the web application's permissions. That usually means database credentials, API keys and a foothold to pivot inward. Root isn't required to do real damage.

What to do

  1. Patch now. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later. On 7.4, 8.0 or 8.1, upgrade to a supported branch or apply your distribution's backported fix. Don't wait for a "confirmed exploited" headline.
  2. Inventory every PHP runtime, including appliances, vendor images, containers and forgotten staging hosts. Ask suppliers for their patch timelines in writing.
  3. Harden while you patch. The observed tooling depends on session.upload_progress.enabled=1, session.use_strict_mode=0 and display_errors=1. Turning upload progress off, enabling strict session mode and keeping error display off in production removes preconditions it relies on. Treat this as defense in depth, not a substitute for the fix.
  4. Hunt. Look for unexpected files in PHP session directories, new PHP files in web roots, outbound connections from web servers to unfamiliar hosts, and Linux ELF downloads by the web user.
  5. Block known infrastructure at the edge and in DNS, including the C2 134.199.154[.]64 (TCP 50792), the domain thunder.godofthunder[.]st, the loader host 92.118.112[.]100 and the exploitation server 206.188.197[.]105. Expect these to rotate.
  6. Rotate secrets (database passwords, API keys, cloud tokens) on any PHP host that was internet-facing and unpatched, especially if you see signs of probing.

Finding every outdated PHP build across a sprawling estate is exactly the job vulnerability scanning is built for. Our team's scans identify engine and framework versions on each exposed host and flag the ones carrying known critical CVEs like PHP2Shell, so the patch list comes from evidence, not memory.

Reporting on this story was first published by The Hacker News; this article is our independent summary and analysis.

SHARE