PHP2Shell Exploit Attempts Hit Millions: Mirai Botnet, ASLR Bypass and What to Do Now

Every PHP2Shell exploit attempt seen so far has failed. That is the surprising headline two days after PHP shipped emergency patches for CVE-2026-109618 and CVE-2026-109619. Cloudflare saw tens of thousands of exploit attempts within 45 minutes of the announcement, and millions by early October 22. Botnet operators have tried to use the bugs to install Mirai malware. A financially motivated crew built a "one-click" exploit and tested it against live websites. Yet as of October 23, no security vendor watching this traffic has confirmed a single successful break-in.

That is good news, but it is not a reason to relax. In the same 48 hours, researchers at VulnCheck showed that the hardest part of a PHP2Shell exploit can be beaten on a normally configured server, and PHP warned about a third, separate code-execution bug. If you missed the background, start with our PHP2Shell explainer. This post covers what attackers are actually doing now, why they keep failing, why that may not last, and how to check whether your servers were targeted.

The short version

• Patch PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. The bugs are in the PHP engine itself, so updating WordPress, Laravel or your own code does not fix them.

• Exploit attempts are now in the millions, mostly scanning, plus a Mirai botnet campaign called Potassium.

• No confirmed successful exploitation as of October 23. Several vendors say reliable code execution is harder than first expected.

• VulnCheck has built an exploit that defeats ASLR on x86-64 servers with PHP's recommended production settings. The main obstacle attackers face can be overcome.

• A new, separate bug, CVE-2026-115560, is not patched yet. Setting session.upload_progress.enabled=0 covers it.

• PHP 7.3 and older will never be fixed. Expect a long tail, like Log4Shell.

A quick refresher: what PHP2Shell is

PHP2Shell is the name for two memory-safety bugs in PHP's core request handling. Both are rated 9.2 on CVSS v4.0 and can be exploited remotely without logging in.

• CVE-2026-109618 is triggered when PHP runs out of memory partway through setting up a request. The cleanup code can then treat half-built internal data as valid.

• CVE-2026-109619 involves request state that survives after its memory has been freed, so the next request on the same PHP worker can use stale data.

Sysdig's researchers point out that the vulnerable code goes back to PHP 5.4, released in 2012. Because the flaw lives in the engine and not in any application, a WordPress, Drupal or Joomla site with perfectly clean code is still exposed if it runs on a vulnerable PHP build. Details leaked on October 20, ahead of the planned coordinated disclosure, and PHP pushed fixed releases at 14:00 UTC on October 21.

Millions of PHP2Shell exploit attempts, zero confirmed breaches

PHP2Shell exploit attempts went from zero to millions in about a day.

The speed was remarkable even by recent standards. Cloudflare reported tens of thousands of exploit attempts 45 minutes after the flaws were announced. That rose to hundreds of thousands within two hours and to millions by early October 22. Previdian recorded the first exploit attempt against CVE-2026-109618 at 1:05 p.m. UTC on October 21, before PHP's fixed releases were out.

What all those requests actually do is less dramatic. Cisco Talos described most of it as scanning, "along with some uncoordinated attempts to deliver various payloads." Previdian, Beelzebub, Dataminr and Wordfence all reported the same pattern from their honeypots and customer sites:

• Fingerprinting PHP versions and server setups

• Trying to confirm that a command ran

• Trying to read credentials and secrets from environment variables

• Trying to plant persistent access, such as a web shell in a server-side session file

• Trying to download and run a second-stage payload

Previdian put it plainly: "At the time of writing, we've observed no successful remote code execution and no dropped PHP files. Reliable RCE may be harder to achieve than initially expected."

Why this matters: a flood of failed attempts tells you attackers are interested and still searching for a reliable method. It does not tell you that your unpatched server is safe.

The Mirai botnet angle: meet "Potassium"

The most organized PHP2Shell exploit campaign so far comes from botnet operators. Sophos and Arctic Wolf both tracked attempts to use the flaws to install a variant of Mirai, the botnet family that has been turning servers and IoT devices into DDoS weapons since 2016. This variant, called Potassium, was first flagged by the botnet tracker Synthient in March 2026.

The Potassium PHP2Shell exploit chain works roughly like this:

1. Attack traffic arrives from three IP addresses and tries the PHP2Shell exploit.

2. On success, the target would fetch a loader from a separate server.

3. The loader installs the Mirai variant, which looks up the domain thunder.godofthunder[.]st and connects to its command server on TCP port 50792.

4. The bot downloads further payloads, checking that each one is a Linux ELF binary, and waits for attack orders.

In Sophos's sandbox tests, the end goal was sustained flood attacks against two neighbouring hosts on a single Ukrainian network. Arctic Wolf counted 24 attack commands covering ICMP, TCP, UDP and OpenVPN floods, with builds for both ARM and x86.

A few details show this is a maintained piece of malware, not a script-kiddie copy:

• Nokia Deepfield found it encrypts its config with ChaCha20, the first time it has seen that in a Mirai variant.

• It hides its real command server by swapping the two halves of every IP address it resolves through DNS.

• It carries a reverse-shell feature on the same channel it uses for attack commands.

• It contains a disabled option to find its command servers through the Ethereum Name Service (ENS). Arctic Wolf warned that if a future version switches this on, the botnet will be harder to take down, because it would no longer depend on domain registrars or DNS providers.

Sophos's verdict is the reassuring part: the lack of any successful attack suggests the operators are "struggling" to build a reliable PHP2Shell exploit.

A "one-click" exploit found on an attacker's server

A second group is more targeted. SOCRadar found PHP2Shell exploit tooling on an exposed attacker server. The main file, aslr_exploit.py, is labelled a "one-click" exploit for PHP 8.4.26 running under Apache mod_php. According to SOCRadar, it works entirely over normal HTTP requests in three stages:

1. It forces the target's PHP worker to recycle.

2. It leaks memory addresses through the session cookie to defeat ASLR.

3. It abuses PHP's session upload progress handling to run a shell command.

Before firing the PHP2Shell exploit, three helper scripts did the reconnaissance. One read the PHP version and server setup from about 20 public websites in Canada, China, Finland, France, Poland, the UK and the US. Another probed 11 of those for exposed errors, phpinfo() pages and session settings. A third enumerated users and plugins on five WordPress sites.

None of the screened sites showed signs of compromise, which suggests they didn't meet the exploit's narrow requirements. Hunt.io, which tracked the same server, said the operator went on to target 123 servers. About 57 ran PHP, many on unsupported 5.x to 7.x releases. Ten rejected the requests outright, including three of the five behind Cloudflare, and none were exploited.

The wider toolkit is the more worrying part. SOCRadar found tools for pulling API keys and backend URLs out of websites' JavaScript, sweeping API routes for endpoints with no authentication, rotating proxies to dodge rate limits, and solving CAPTCHAs automatically. Its assessment is that the operator is financially motivated and focused on cryptocurrency and Web3 targets. If you run a crypto or fintech product on PHP, assume you are on this kind of list.

Why PHP2Shell exploit attempts keep failing, and why that may change

The main obstacle is ASLR (Address Space Layout Randomization). It's a defence built into modern operating systems that places a program's code and data at random memory addresses each time it starts. To turn a memory-corruption bug into working code execution, an attacker usually needs to know where things are in memory. ASLR means guessing, and wrong guesses usually crash the worker instead of handing over a shell.

The exploit also depends on preconditions that many servers don't meet: a specific PHP version, a specific server mode such as mod_php or PHP-FPM, particular session settings, and sometimes error output that leaks internal details.

That barrier has now been crossed in a lab. Spencer McIntyre, director of exploit development at VulnCheck, said his team built a technique that chains the two bugs together, uses a memory leak to bypass ASLR, and achieves code execution on x86-64 systems "even with PHP's recommended production error-display setting." He added that they hadn't seen any other public or commercial exploit work under the same conditions.

VulnCheck hasn't released its exploit, but the lesson from previous bugs is that once a technique is known to be possible, others follow. In the Node.js world this week, a similar "2Shell" bug went from crash-only proof-of-concept to working code execution in about a day.

McIntyre also explained why a web-app foothold is serious even without root access: "An attacker doesn't necessarily need administrator or root access to cause significant damage." Code running as your web application can read its API keys and database credentials and reach any internal service the app can reach.

CVE-2026-115560: the new bug you also need to know about

On October 23, PHP published an informational advisory for a third issue, CVE-2026-115560, which may also allow code execution. It is not fixed by the PHP2Shell releases, and PHP is not issuing an emergency patch for it. The fix will come in the next regular release.

The good news is that it only affects an unusual setup. An application is exposed only if all of these are true:

• session.serialize_handler is set to php_binary or php_serialize in your configuration

• The application switches it to php at runtime with ini_set()

• That switch happens before session_start()

• Session upload progress is still enabled

PHP's recommended mitigation is the same setting it listed for CVE-2026-109619: session.upload_progress.enabled=0. If you applied that on October 21, you're already covered.

What to do now: a PHP2Shell checklist

1. Patch the runtime that serves web traffic

PHP branchFixed versionStatus8.58.5.12Supported8.48.4.27Supported8.38.3.36Supported8.28.2.35Supported8.1, 8.0, 7.4Source backports onlyEnd of life: upgrade, or use a distro or vendor backport7.3 and olderNo fixEnd of life: must upgrade

Be careful how you check. php -v reports the command-line PHP, which can differ from the PHP-FPM or mod_php build that actually serves your site. Check the web runtime through your hosting panel or a temporary phpinfo() page that you delete straight afterwards. If you run PHP in containers, our PHP2Shell Docker update and rollout checks cover rebuilding images and confirming what's actually running.

Distributions such as Debian, Ubuntu and RHEL often backport the fix without changing the upstream version number. Check your distro's security advisory for the patched package version rather than relying on the version string alone.

2. Apply PHP's interim mitigations if you can't patch today

PHP listed these as temporary measures only. They lower risk but don't remove it:

• For CVE-2026-109619 and CVE-2026-115560: set session.upload_progress.enabled=0, then restart every PHP worker. On PHP 8.5, also set fatal_error_backtraces=0.

• For CVE-2026-109618: PHP suggests lowering post_max_size (8M without file uploads, 32M with them), enforcing request size limits at your web server or proxy, and preferring container or cgroup memory limits over RLIMIT_AS.

• Fix any errors or timeouts an outsider can trigger, and turn off error display in production.

; php.ini — interim PHP2Shell mitigation
session.upload_progress.enabled = 0
display_errors = Off

Under Apache mod_php, .user.ini files are ignored. Put the setting in php.ini, the virtual host config or .htaccess. Then confirm the value on the process that serves your site, not with php -i in a shell.

3. Lean on your edge, but don't trust it alone

Cloudflare has deployed emergency WAF rules, including on its free plan, and Hunt.io's data suggests they did block some attempts. Cloudflare itself calls them a stopgap. They only protect traffic that actually passes through Cloudflare, so make sure attackers can't reach your origin server directly by IP address.

4. Check whether you were targeted

Even without a confirmed breach, it's worth checking for signs of a PHP2Shell exploit attempt, especially if you were slow to patch:

• Web server logs: search for the attacker IPs below, and for unusual multipart requests or bursts of requests designed to crash and recycle PHP workers.

• Unexpected files: look for new or modified .php files in your web root and odd content in your PHP session directory, since one attacker tried to plant a web shell through a session file.

• Process and network activity: look for sh, curl or wget launched by your web server user, and outbound connections to the IPs, domain or port 50792 listed below.

• Secrets: if you find anything suspicious, rotate the API keys, database passwords and cloud credentials stored in that server's environment variables, because several payloads tried to steal exactly those.

Indicators of compromise

These come from Sophos, Arctic Wolf and Wordfence via The Hacker News. Dots are written as [.] so they can't be clicked; remove the brackets before adding them to blocklists.

TypeIndicatorContextAttack source85.11.167[.]243, 217.60.242[.]76, 45.198.224[.]169Potassium (Mirai) exploit attemptsLoader host92.118.112[.]100Serves the Mirai loaderC2 domainthunder.godofthunder[.]stResolves to the C2 belowC2 server134.199.154[.]64 (TCP 50792)Potassium command serverExploit server206.188.197[.]105:9999"One-click" exploit and recon scriptsAttack source87.121.84[.]174, 181.215.186[.]252, 185.196.220[.]132, 185.161.210[.]29, 152.233.51[.]69Wordfence-observed attemptsAttack source45.134.225[.]16, 107.189.14[.]87, 193.47.62[.]24, 103.147.220[.]17Wordfence-observed attempts

Attackers rotate infrastructure quickly, so treat these as useful for searching your logs, not as a complete blocklist.

The long tail: why PHP2Shell won't go away soon

The real impact of PHP2Shell will play out over months, not days. Censys detects more than 3.08 million hosts and 56.6 million web properties running PHP, and estimated that more than 34.4 million PHP services were still vulnerable as of October 23. PHP 7.3 and older will never get a fix, and plenty of commercial products bundle their own PHP and must wait for their vendor to ship an update. Dataminr expects many organizations to "remain vulnerable to some degree for far longer" than those who control their own stack.

The disruption is already real. Government, school and hospital websites across Asia, Europe and North America went offline as a precaution. The UK government confirmed 32 digital services were unavailable and four partly unavailable while patches were applied, and the National Cyber Security Centre sent about 50,000 warnings to organizations.

So the failed PHP2Shell exploit attempts are a gift of time, not a guarantee. Attackers have the motivation, the tooling and, thanks to VulnCheck, proof that the hardest step can be solved. Use the time to patch the runtime, apply the interim settings where you can't, and check your logs. If you manage several servers, our guide to PHP2Shell patches for PHP web servers walks through the rollout.

Sources: The Hacker News: exploit attempts hit millions · The Hacker News: CVE-2026-115560 · The Hacker News: what actually protects you · SOCRadar: affected versions and fix