PHP2Shell and potassium: four RCE paths, the DDoS bot pushed through them, and the operator behind it

Four RCE paths from one flaw#

Three CVEs in PHP's session upload-progress feature produce four distinct remote-code-execution paths. All four were demonstrated end to end in our lab on stock php:8.3.35-apache (mod_php prefork, default configuration). Three are memory-corruption chains fixed in PHP 8.3.36 / 8.4.27 / 8.5.12. The fourth, CVE-2026-115560, is a different bug class: it reaches code execution only with an application framework present, and it is unpatched as of late October 2026.

All four begin at the same stumble. A crafted request makes PHP run out of memory in the middle of parsing, and PHP's internal "give up and unwind" jump (zend_bailout) skips the cleanup that a normal request runs. What that skipped cleanup leaves behind decides which path opens.

The paths at a glance#

All three memory-corruption paths were confirmed on default configuration: 14 segfaults in 15 rounds on the vulnerable build, and 0 crashes in 261 rounds on the patched build with byte-for-byte identical traffic. The session file on disk is never corrupted; the damage lives entirely in the running worker's memory.

How each path works#

These descriptions stay at the level of PHP's own advisories. The step-by-step exploit-development detail (heap grooming, the reclaim carrier, the gadget chain) is not published.

CVE-2026-109618, big-field out of memory. A multipart POST with a file part and an oversized field value exhausts memory_limit mid-parse. The bailout skips session cleanup and leaves a dangling reference. A follow-up request reclaims that freed slot and redirects a destructor so the engine runs a command as the web-server user. Two preliminary requests leak the addresses the reclaim needs.

CVE-2026-109619, filename out of memory. The same corruption and the same end, reached by a different trigger: an overlong upload filename exhausts memory from a single header field. A preceding file part is required, so the progress array is populated and the stale reference survives into the next request. Zero-byte file content is enough.

CVE-2026-109618, unserialize dual primitive. The one out-of-memory bailout can leave two independent globals in a bad state at once: the session reference above, and the session unserializer's own bookkeeping, which yields an arbitrary write. Our proof of concept chains both from a single follow-up request, showing the two primitives are reachable and composable, not just one or the other.

CVE-2026-115560, serializer mismatch (unpatched). A separate bug. The upload-progress callback writes session data with the server-configured serializer before application code runs; if the application later switches serializers, attacker-controlled input can be deserialized into a live object. On stock PHP this reaches no code execution, because the standard library ships no usable destructor gadget. With a framework that has one (the PHPGGC catalog lists dozens), it does. This affects fully patched builds. The trigger and the gadget path are withheld here until a fix ships.

Detection#

The original detection suite was built against the wrong assumption, that the attack would look like a large, loud payload. Against the real crashing traffic only one of the first fifteen signatures fired. We rebuilt and engine-validated the suite directly against the functional attack. The rules below detect the attempt; a request that fails to corrupt memory is a failed attempt at the same attack, not benign traffic, so alerting on the shape is the right call.

Request-side (Suricata)#

Response-side (Suricata)#

Host-side signals#

The reliable detector is the ordered triple: request 1 logs Allowed memory size exhausted, then request 2 returns HTTP 200 while logging Failed to write session data, with no worker reap and no allocator-corruption line. Each signal alone is ambiguous; the ordered triple is not. It catches both the crash and the silent use-after-free exits of the memory-corruption paths. It does not catch the serializer mismatch.

What is not covered#

• The published big-field proof of concept uses a urlencoded body with an oversized field name, not multipart. The multipart-keyed rules miss it; a dedicated rule is drafted but not yet baselined.
• The serializer-mismatch injection. A generic rule can alert on PHP serialized-object markers (O:, a:) appearing in an upload-progress field value. We hold the precise, higher-fidelity signature with the trigger until CVE-2026-115560 is patched.
• The silent use-after-free has no wire-side signal at all. The worker survives and returns 200; the only tell is the host-side Failed to write session data line.

Mitigations#

The malware: potassium, the second stage#

Within hours of the patch, attackers were using this flaw to plant a second-stage bot. We obtained the sample and ran it through CORD Research, a static analysis pipeline; nothing was executed. It is far more than a run-of-the-mill Mirai copy (Mirai being the widely copied botnet code most Linux DDoS malware descends from). It is the newest build of a family Nokia Deepfield documented in May 2026 as potassium, and the binary the research firm ELLIO identified on 2026-10-22 as the PHP2Shell second stage, seen in the wild the day before.

Read the full CORD report for 0c5486f0 → It has every behaviour with its evidence, all 461 decoded strings, the static process map, how the code connects, the decompiled C and annotated assembly of every function read, and the evidence index.

Verdict: malicious · botnet payload · family Mirai (potassium lineage), confidence 0.55.

Code reached is 475 of 546 functions from the entry. Of the 31 network indicators, 15 are command-and-control hosts.

How it runs#

The scanner classic Mirai uses to spread on its own has been removed: this build is placed deliberately by a loader, not spread like a worm.

What it does#

How the code connects#

The string-store decryptor (FUN_0040dba0 and its helpers) runs first; every later behaviour reads its names, hosts and paths from that store. The main routine (FUN_004001d0) takes the lock, daemonises and enters the C2 loop (FUN_00411ca1 and the session functions around it), which dispatches commands: the attack table and its forked workers (FUN_00400f7d, FUN_00400cd7), self-update (FUN_0040c42a, FUN_0040b89c) and the remote shell (FUN_0040aa12, FUN_0040a948). PID hiding is FUN_0041479d and FUN_00414879. The full report's "How the code connects" section has all 43 call paths, and its "Code" section the decompiled C and assembly of each function.

What it talks to and touches#

• C2 hosts from the string store, slots 0 to 7: thunder[.]godofthunder[.]st; plus hackattackkaboom[.]botlesscucks[.]st and hik[.]gettingheadfromduckysmom[.]st.
• An Ethereum fallback: ENS names 2sexy4u[.]eth and sushiconsumer[.]eth, read through public RPC endpoints (see the operator).
• 14 C2 ports, a loopback lock on TCP 1234, /var/tmp/.cache/sysd, the watchdog devices, and the 18 public DNS resolvers it carries for its own lookups.
• The published DNS answers for its C2 hosts are decoys; the real addresses are recovered under the operator. The full list is in the appendix.

Decoded strings#

CORD decrypted the ChaCha20 store and decoded 461 entries: C2 hostnames, the ENS names and resolver recipe, RPC endpoints, ports, process names (telnetd, udhcpc, upnpd, watchdog, syslogd and others), shell and watchdog paths, and the lineage markers Segmentation fault (core dumped), big brother is watching, dvrInside, dvrLocker and im in the matrix. All 461 are in the full report.

Verdict and detection opportunities#

Malicious botnet payload of the Mirai lineage. CORD proposed five detection features at build, family and technique scope; four YARA rules built from them are below under Detecting and blocking the malware, with no hits on clean software.

Open questions#

CORD's six open questions: 23 of 484 string-store sites fail its printable check; where the 32 bytes behind the C2 peer key live and the exact hash and MAC primitives of the session; the shell relay at 0x40a31c and its message check at 0x40b0b8; the protocol and packet template of each of the 24 attack vectors at 0x62b000; what the read-only marker page at 0x62bdc0 is for; and the reach of 9 user functions and 28 unresolved computed calls.

The wider family and our confidence#

This sample is one build off a production line. We scored every related file in our own collection and ran four detection rules back across a year of global malware submissions. Here is what came back, ranked by how sure we are:

• Same operator, high confidence. Two x86-64 "sibling" builds, 6f272c85365a… (2026-10-04) and b58cf55ad3e6… (2026-09-23), carry the same encrypted blockchain settings and overlapping control-server lists once decrypted. This sample and 6f272c85365a… share two of the very same control-server hosts outright. The blockchain seals it: both build lines registered their names through the same service and point at the same operator-specific resolver, tying them together on a public ledger.
• Same operator, likely. Six ARM builds from September and October 2026, one of which (5420b2745e8d…) was seen reaching the exact same control server as our sample.
• Same toolkit, operator unproven. Three un-stripped "developer" builds that accidentally shipped with their source-file names intact, revealing the project's internal module layout, plus two older ARM builds.
• Fresh finds (2026-10-22). Our retrohunt surfaced 23 more in-the-wild builds not previously in our corpus: six x86-64 and seventeen ARM/SuperH/x86, including versions bundled inside Android app packages. Our four detection rules flagged all of them with zero false alarms against clean software.

In short: this is an actively maintained, multi-platform family, from Linux servers to Android devices, not a one-off.

The operator#

The crew is careful, but careful people are consistent, and consistency makes a pattern. The pattern led us a long way.

Their infrastructure#

They rotate their control-server domains like clockwork: a new .st domain every few weeks (with one two-month lull over the summer), bought through two small resellers, each dressed up with a legitimate-looking web page, with the real control servers tucked away on short subdomains. Their hosting spans Estonia, France, Switzerland, Russia, Armenia and DigitalOcean. New infrastructure typically goes live about a week before a new malware build ships, a rhythm regular enough to track.

The sleight of hand: decoy DNS#

When the bot looks up its control domain, it never connects to the address it gets back. It scrambles that address first: older builds swap the two halves; this build keeps the first number and rotates the rest, then connects to the result. The addresses anyone can see point at university, military and ordinary consumer networks: innocent bystanders. Blocking the published address does nothing, and would hurt the wrong people. We worked the scramble backwards and recovered the real servers, including the live one at 134[.]199[.]154[.]64 (DigitalOcean), plus eight more behind the group's other hosts, two of them this sample's own second domain.

A C2 fallback on the blockchain#

Buried in the configuration is something new: a backup plan. If the domains are ever taken down, the bot can look up its control-server address on the Ethereum blockchain instead, a public ledger that no registrar or hosting provider can switch off. It is wired to read a text record (labelled ip) from three blockchain names: 2sexy4u[.]eth and sushiconsumer[.]eth (this sample) and catswithhatslolksjhakf[.]eth (the siblings), through a fixed registry (0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e) and resolver (0xf29100983e058b709f3d539b0c765937b804ac15). This build does not use it yet; the feature is built and tested but not switched on. The values parked there appear to be scrambled with the same decoy trick: unwinding three of the October values with this build's scramble lands them in the same DigitalOcean range as the live server. Read it as a glimpse of where the family is heading: a fallback that no domain takedown can touch.

Following the money#

Because the blockchain is public, we could read who owns those names and who paid for them. This is the strongest thread in the whole investigation:

• Two wallets, one playbook. The sample's two blockchain names sit in one wallet (0x32ab9ef9…da7b); the siblings' name sits in a second (0xd5e34876…f995). Both registered through the same service and point at the same operator-specific resolver, an on-chain tie between the two build lines, on top of the control-server hosts they already share in their code.
• That second wallet is a smart contract, an account-abstraction setup that keeps the controlling key off the public ledger. It has been active since 2025 (see the wallet appendix), so it is a wallet held in reserve rather than spun up for this campaign.
• Both wallets were funded through throwaway relay wallets: pass the money through once, then discard the wallet. A pattern meant to break the trail. They used no mixer like Tornado Cash; the one anonymity step is a single no-KYC swap (ChangeNOW) on one branch, so the trail is bent, not cut.
• And both branches of that trail now reach exchanges that know their customers. The relay that seeded the smart-contract wallet was itself funded, on 2025-06-10, by a Coinbase hot wallet (0xb5d85cbf…). Coinbase is a KYC exchange: it verifies who its account holders are. That withdrawal is tied to a real, identifiable account the exchange can name under legal process. This is the single most promising lead toward the people behind the group.
• The other wallet's trail, which we had stopped one step short of, is now fully followed (26 October). It runs through a busy, shared cash-movement service on the blockchain. Money comes into that service from a KuCoin exchange wallet (0x45300136…) and leaves it to a Binance deposit address (0x16f59CEf…), with one deliberate detour through ChangeNOW (0x3f3Ee0a9…), a swap service that asks for no identity. Because that service moves money for many unrelated people, KuCoin and Binance here are leads to confirm, not proof on their own. The upshot: every branch of the money ends either at an exchange that keeps customer records (Coinbase, KuCoin, Binance) or at the no-identity swap the operator used to break the chain. From here on, naming anyone means going to those exchanges with legal process, Coinbase first. Attribution stays with the operator group; no individual is named.

What their tradecraft tells us#

They are competent and deliberate: encrypted builds, rotating infrastructure, decoy addressing, disposable funding wallets, a blockchain fallback waiting in the wings, and wallet keys kept off the public record. But the discipline is uneven. They let developer builds slip out with their internal file names intact, and the money trail still touches a named exchange. Two soft signals, which we hold loosely, point toward a European operator: their blockchain activity clusters in a 06:00–14:00 UTC window (European working hours), and Deepfield observed Dutch-language content in an earlier campaign.

Detecting and blocking the malware#

• YARA. Four rules cover the family across architectures with no hits on clean software (16,686 ELF samples, 4,699 Linux system binaries and 1,542 Windows files tested): elf_mirai_ext_x64_build_family, elf_mirai_ext_x64_chacha_lineage, elf_mirai_ext_multiarch_literals and a survey rule for triage. All four in one file: potassium-all.yar.
• Block the real control servers in the appendix, never the published DNS answers, which are decoys pointing at bystanders.
• On Linux hosts, look for a loopback listener on TCP port 1234, a hidden directory at /var/tmp/.cache/sysd, files at /tmp/.manta or /tmp/.xwiki, and a process whose /proc entry is masked by another.
• Proactively, watch the three ENS names for record changes (a read-only query), watch for new .st domains from the same two resellers, and pivot on the relay wallets.

Appendix — full indicators#

Collected 2026-10-22 from the decrypted store of the sample, the decoded stores of the two x86-64 siblings, VirusTotal relationships and passive DNS, and read-only Ethereum mainnet lookups. Published DNS answers of the C2 hosts are decoys (the address-rewriting trick described in Act III) and are listed apart; do not block them.

A1. The sample#

A2. Hostnames in the sample's string store#

A3. ENS resolution recipe (store slots 11-20)#

A4. Ethereum mainnet state of the ENS names (read-only lookups, 2026-10-22)#

ENS registry 0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e; selectors resolver(bytes32) = 0x0178b8bf, text(bytes32,string) = 0x59d1d43c; text key ip.

Record history (Blockscout log API, read once on 2026-10-22; the values of the superseded records were not retained and a re-read was rate-limited): the first name has NewResolver events on 2022-05-24 and 2026-10-13 and eleven TextChanged events with keys ip, ip1, ip2, ip4, readme, of which four ip changes within hours on 2026-10-14 over three distinct values; the second name has one NewResolver on 2026-09-10 and one ip set on 2026-09-11; the third has one NewResolver on 2026-10-13 and no text record.

Public RPC endpoints in the store (the bot would use these; they are legitimate providers and not blockable indicators): ethereum.publicnode.com, ethereum-rpc.publicnode.com, eth.drpc.org, 1rpc.io, eth-mainnet.blockreq.com, ethereum-public.nodies.app, rpc.mevblocker.io.

A5. Ports, process names, paths, resolvers#

• C2 ports (random pick from 14): 50217, 50341, 50488, 50613, 50792, 50904, 51127, 51289, 51456, 51603, 51871, 52134, 52398, 52645
• loopback single-instance lock: TCP 1234 (retry counter 0x1a); stock Mirai uses 48101
• process names adopted after daemonising (prctl and argv[0]): telnetd, udhcpc, upnpd, watchdog, syslogd, klogd, uhttpd, uchttpd
• potassium markers in the store: Segmentation fault (core dumped), big brother is watching, dvrInside, dvrLocker, im in the matrix
• shell paths: /apex/com.android.runtime/bin/sh, /data/local/tmp/sh, /sbin/sh, /system/bin/sh, /usr/bin/sh, /vendor/bin/sh
• watchdog devices: /dev/misc/watchdog, /dev/watchdog
• on-disk install path seen in VirusTotal in-the-wild names of core builds: /var/tmp/.cache/sysd
• additional drop paths seen in retrohunt matches (2026-10-22): /tmp/.manta, /tmp/.xwiki
• embedded DNS resolvers (18, used for the bot's own lookups; legitimate public resolvers): 8[.]8[.]8[.]8, 8[.]8[.]4[.]4, 1[.]1[.]1[.]1, 1[.]0[.]0[.]1, 208[.]67[.]222[.]222, 208[.]67[.]220[.]220, 9[.]9[.]9[.]9, 149[.]112[.]112[.]112, 94[.]140[.]14[.]14, 94[.]140[.]15[.]15, 114[.]114[.]114[.]114, 114[.]114[.]115[.]115, 223[.]5[.]5[.]5, 223[.]6[.]6[.]6, 119[.]29[.]29[.]29, 180[.]76[.]76[.]76, 64[.]6[.]64[.]6, 64[.]6[.]65[.]6

A6. Domains#

Siblings' C2 hosts by store slot: 6f272c85365a: dvrs[.]botlesscucks[.]st, dvrs2[.]botlesscucks[.]st, dvrs4[.]botlesscucks[.]st, hackattackkaboom[.]botlesscucks[.]st, hik[.]gettingheadfromduckysmom[.]st; b58cf55ad3e6: dvrs[.]botlesscucks[.]st, dvrs2[.]botlesscucks[.]st, dvrs4[.]botlesscucks[.]st

A7. Real C2 and hosting addresses#

Published by ELLIO (2026-10-22) for the same sample: C2 address 134[.]199[.]154[.]64 (DigitalOcean, reached through the rotation from the decoy 134[.]154[.]64[.]199), update host 117[.]55[.]202[.]115, staging host 92[.]118[.]112[.]100 (AS215540) serving hxxp://92[.]118[.]112[.]100/nfs, loader source 45[.]198[.]224[.]169. Of these, the C2 address appears among the contacted addresses of our relatives and the update host is the EE address above.

A8. Decoy DNS answers (do not block)#

A9. URLs#

A10. Execution parents and files tied to the infrastructure#

Execution parents (droppers and scripts that ran a relative):

Files not in the corpus that communicate with the group's domains or real hosting (79):

In-the-wild file names of the core builds: arm7, arm5, sh4, x86_64.elf, nfs, numeric names, and /var/tmp/.cache/sysd.

A11. Operator wallets (Ethereum, read-only lookups 2026-10-22)#

A12. Related sample hashes#

High-confidence siblings (same operator):

• 6f272c85365a1783eedbf7bc80112db52d13bca5415703df127b869b23bc179f (x86-64, 2026-10-04)
• b58cf55ad3e632086b1fa91989a38ea5266530eb0f52ee54eb81ad4edc49cc48 (x86-64, 2026-09-23)

Likely same operator (ARM):

• 5420b2745e8d8c347563d73c3945b50b12f7c21b38fbfefd0202779fe1fa98c1
• 07b98716aa3f8991a377340cf55b335e8f7fc62425c3762fa11d53b91d427521
• 8329ed49c67ab2a0f02b6c43ffda4aa2f3ff6a7599a2a9769aabb121cbcbfa87
• bc6854418c71d63e9209be6260fdc76517603fb9c1bdbcabb9858043207a418d
• 9ae981175d5e8cf979faf9c4e3e13b3b8270c52a707b3ffc3e6f53b37ea091d2
• a2b38e3080c9a3c53dff1216cb8d8e8b773e10d95523f2ce518c2a41b2b124e3

Builds surfaced by the 2026-10-22 retrohunt (not previously in our corpus):

• x86-64: 6b138dd673640dc611a8b5883301e5b77e6564d43a8462264f50260f674a8ef4, 2d3af69a38b0bee1a059a0d4ce907f8bb2128f25a753fff0f84f48ddcb9592c6, c1351f990db3f775e6774194a457081a9f8cea3e57d6d182767fd86551a82c39, 7f436c109405ec81a44f52d33f2ba3276c797238729dad09f299a84147fbc8d5, b85897f6378ff42ec4934f574c8ca447d2c37fe58d0ab7f877fdf48e0522ec6f, 3a032308c72fe33ddd89f03d9f64e2c56cad5fb0dc6ed8e3d3c6eb684108b629
• ARM / SuperH / x86: 3461b097ea026c9161113f0f590e75c47908cebd3d6a30de3b821c10a85ea9fc, c475cf4e7877b792544783d3edeb028882df09ee5363ab7f90ce11e14c41cb26, e36e40cfdd57ce91c7d349f42b0e7768aa233337166c15e7f215d081df9c0ba9, b200ab6d281055e113fe82fbd7d4fef86183221a4a68c6154ab8ca6fc08c34fb, 44a6090b72ff9094a862f13a14ff333fcf19b41eb58af9c0bd54f23834c175fa, 7fc40677a79d0cbc675d8c0042d6cfbc87ca1a9982f5046008feb7bd4fe799b9, 10c7853e6dc953e6b805cef03a7324caf6c87e68117a7c3175feb463c5c9c0e0, 01c70849ed30aa1cc4e08cb7529b62c2e3a9044ad0ab000ad84a343444a8dd5a, 6a1cefffb07c9a6d58f42f1ed686e4ff7de0f70196d6fef76f424f219e36a315, 3f50a7629d8d324e7a614cf89881822b89bb37d26fe0852e7ebf5173b5340d29, 2b32143e21c0b2ceed37f1100d3a3d42379c48c6d4163f31e25aa524bea34a14, b78ae1663194190fb8c92cf1f436ad892c08d51fdbe8cccdaa12e539988e731a, 5997a6f80b25f550c5e7617bceac4477c580057846f8061e7165d1fbfa89f30a, 73308b7c5982e99b90075f4d48583c00bb984f1765bc6bd5a01ff3b1bbdd5f51, f54f5cec97c24c3eb24f095be8c464b87f4dfc37c0d2f9507b020b24dcf28dd9, c65bca6729f694f1b0c806c30c76c54a70e3d32c8981bbe0f62428028b78db6d, e2529d4afa39ae4db2eb05d5176317c906289abf09660c75bdeec43e54c55aa3