PHP2Shell Scanners Left Their Toolboxes Open, and Hunt.io Looked

Some of the people scanning for PHP2Shell left their tool folders open to the internet, and Hunt.io went through them. The threat-intel firm says it found about ten attacker open directories holding PHP2Shell tooling, plus a Mirai-style IoT botnet that has added the bug to its spreading kit. The useful part for defenders is a set of attempt signatures and indicators. Hunt.io is clear that none of the activity it tracked produced a confirmed PHP2Shell compromise, but Amazon has separately said exploitation is now broad, as we covered in our MadPot story.

45.198.224[.]0/24 (scanner network, AS215925)
85.11.167[.]243 (scanner)
92.118.112[.]100 (payload host)
89.32.41[.]16, 89.32.41[.]50, 45.198.224[.]88 (botnet binaries)
*.botlesscucks[.]st, *.godofthunder[.]st, *.gettingheadfromduckysmom[.]st (botnet C2)
maste.mangsud[.]org (payload source in staged shell.php)

User-agent contains: php2shell (seen as php2shell-scan/109618, php2shell-109618)
JA4H: po11cn050000_0a87faf13e54_fe81d65a9ab0_0b5a6e5841d5
Staging: 206.188.197[.]105:9999, 58.221.60[.]160:8000, 104.219.251[.]31:8123, 102.210.149[.]166

Source article: Hunting Leaked PHP2Shell RCE Across Open Directories (CVE-2026-109618, CVE-2026-109619)
Publisher: Hunt.io (no author named)
Published: Oct. 22, 2026 (page metadata updated Oct. 28, 2026)
URL: https://hunt.io/blog/php2shell-cve-2026-109618-109619-open-directories

Executive Summary

Hunt.io examined about a dozen attacker-run open directories holding PHP2Shell tooling, the pair of unauthenticated remote code execution flaws in PHP core (CVE-2026-109618, an out-of-memory bailout that leaves partially initialized memory in use at request shutdown, and CVE-2026-109619, both CVSS v4.0 9.2, reachable through multipart/form-data parsing with session.upload_progress as the common trigger, and fixed on Oct. 21, 2026 in 8.5.12, 8.4.27, 8.3.36 and 8.2.35). The operators are unnamed and unattributed; Hunt.io describes several independent actors rather than one campaign. The directories show the chain end to end: X-Powered-By version scanning and probes that test whether session.upload_progress is enabled, target lists built around WooCommerce (about 3,000 sites), WHMCS (251) and Magento (131) skewed to the US, Germany, Singapore and the UK, mass-exploitation runs through about 97 proxies (one server ran ten passes between 19:11 and 20:23 UTC on Oct. 21 against a list that grew from 23 to 123 servers), cloned proof-of-concept code with a staged shell.php, and pivots to unrelated bugs such as an AVideo SQL injection when PHP2Shell failed. A Mirai-style IoT botnet active since at least May 2026 has added PHP2Shell to its spreading kit, scanning from VPSVAULT (AS215925) and pulling binaries from separate hosts. Hunt.io recorded no confirmed PHP2Shell compromise as of Oct. 21 to 22 and notes code execution reportedly needs a second weakness or a host without ASLR, so most hits in your logs will be attempts, not breaches. Hunt leads, false-positive expectations, Hunt.io’s published queries and the indicators are detailed below.

ATT&CK chain: Reconnaissance → Resource Development → Initial Access → Command and Control

Hunt Lead Grid

PHP2Shell Scanner, Botnet and Staging Infrastructure Sweep

Hunt.io separates the infrastructure into three groups. The Mirai-style botnet scans from 45.198.224[.]169 on VPSVAULT (AS215925), with the wider 45.198.224[.]0/24 network sharing its fingerprint, pulls payloads from 92.118.112[.]100, serves binaries from 89.32.41[.]16, 89.32.41[.]50 and 45.198.224[.]88, and uses C2 names under botlesscucks[.]st, godofthunder[.]st and gettingheadfromduckysmom[.]st; a second peer-reported scanner is 85.11.167[.]243. The open directories themselves sat on staging hosts, including 206.188.197[.]105:9999 on BL Networks (AS399629, Netherlands), which held aslr_exploit.py, deep_probe.py, c2.py and a proxy list, and 104.219.251[.]31:8123, which held a cloned PoC with a shell.php that pulls its payload from maste.mangsud[.]org. The detection logic has two directions: an inbound sweep of web, WAF and firewall logs for requests from the scanner and staging addresses, and, more important, an outbound sweep of firewall, proxy, DNS and NetFlow logs for any server-originated connection to the payload host, the binary hosts, maste.mangsud[.]org or any name under the three .st C2 domains.

Sweep from Oct. 21, 2026 for the PHP2Shell activity, and back to May 2026 for the botnet’s binary hosts and C2 domains, since the botnet predates PHP2Shell and spreads through other bugs too. Scope inbound matching to every internet-facing PHP host, including appliances and hosting panels, and outbound matching to all servers and IoT devices. Blocking the scanner network and the dedicated payload, binary and C2 infrastructure is a sensible control, but several staging hosts sit on general cloud ranges (DigitalOcean, Linode, AWS, Alibaba), so block those individual addresses rather than their providers. Inbound hits alone show targeting and should feed the request-shape lead; any outbound connection from a server to 92.118.112[.]100, the binary hosts, maste.mangsud[.]org or the .st C2 names means code already ran on that host and should go straight to incident response.

Indicator list from the source article (de-fanged):

# Block (Hunt.io)
45.198.224[.]0/24           # scanner network, VPSVAULT AS215925 (botnet scanner 45.198.224[.]169)
85.11.167[.]243             # second scanner, peer-reported
92.118.112[.]100            # payload host
89.32.41[.]16  89.32.41[.]50  45.198.224[.]88   # botnet binary hosts
*.botlesscucks[.]st  *.godofthunder[.]st  *.gettingheadfromduckysmom[.]st   # botnet C2
# Payload source referenced by staged shell.php on 104.219.251[.]31:8123
maste.mangsud[.]org
# Watch
91.90.123[.]25              # user-agent php2shell-verify/1.0, likely research checker (Belgium)
# Staging and reuse hosts (open directories; no confirmed compromise)
102.210.149[.]166  122.10.110[.]72  122.10.17[.]49  58.221.60[.]160:8000  206.188.197[.]105:9999
41.223.30[.]7  157.230.117[.]70  104.219.251[.]31:8123  107.150.31[.]151  217.160.132[.]82
47.100.125[.]108  54.169.109[.]7  139.162.165[.]136

Hunt Lead Level: 1 (Junior Analyst)

ATT&CK: Reconnaissance → T1595.002 (Active Scanning: Vulnerability Scanning); Command and Control → T1105 (Ingress Tool Transfer); Resource Development → T1608.001 (Stage Capabilities: Upload Malware) for the payload and binary hosts

Sources: “Hunting Leaked PHP2Shell RCE Across Open Directories (CVE-2026-109618, CVE-2026-109619)”, Hunt.io, Oct. 22, 2026, https://hunt.io/blog/php2shell-cve-2026-109618-109619-open-directories (source article)

php2shell User-Agent and Scanner JA4H Fingerprint

The botnet scanner switched its user-agent to php2shell-109618 at 20:36 UTC on Oct. 21, about six and a half hours after the fixes shipped, and other tooling in the wave identifies itself as php2shell-scan/109618; a likely research checker in Belgium uses php2shell-verify/1.0. Hunt.io also shares a peer-reported HTTP client fingerprint for the scanner, JA4H po11cn050000_0a87faf13e54_fe81d65a9ab0_0b5a6e5841d5. The detection logic is a web-log rule for any user-agent containing the string php2shell, plus a match on the JA4H value wherever your WAF, CDN, load balancer or network sensor computes JA4H, with the HTTP status and response size of each matching request recorded for triage.

Use web server access logs for the user-agent branch and WAF, CDN or network sensor logs (Zeek or Suricata with a JA4 plugin, or a CDN that exposes JA4H) for the fingerprint branch. Sweep from Oct. 21, 2026 and keep the rule running. The user-agent is trivially changed, so a quiet result proves nothing, while JA4H survives user-agent changes but not changes to the client’s header order or library, so use both. Do not block on the research checker’s user-agent automatically; Hunt.io places it on a watch list rather than the block list. A match answered with HTTP 403, 405 or 406 by a WAF can be closed after confirming the host is patched; a match answered with 200 or 500 on an unpatched host should move to the request-shape and memory-burst leads on the same host.

Hunt Lead Level: 1 (Junior Analyst)

ATT&CK: Reconnaissance → T1595.002 (Active Scanning: Vulnerability Scanning)

Sources: “Hunting Leaked PHP2Shell RCE Across Open Directories (CVE-2026-109618, CVE-2026-109619)”, Hunt.io, Oct. 22, 2026, https://hunt.io/blog/php2shell-cve-2026-109618-109619-open-directories (source article)

Oversized Multipart POST Carrying PHP_SESSION_UPLOAD_PROGRESS

The bugs are reached through PHP’s multipart/form-data parser before any application code runs, and session.upload_progress (on by default since PHP 5.4) is the common trigger. Tooling in the directories first probed whether a site had upload progress enabled (probe_rfc1867.py on 58.221.60[.]160) and then sent requests built to exhaust memory during parsing. Hunt.io’s attempt signatures are a multipart POST that carries a PHP_SESSION_UPLOAD_PROGRESS field with an unusually large body, and requests shaped to run the parser out of memory, such as a missing content length or large numbers of per-part headers. The detection logic is a request-body rule that fires when a multipart/form-data POST contains the PHP_SESSION_UPLOAD_PROGRESS field and either exceeds a size threshold well above your normal form posts, has no Content-Length, or carries an abnormal number of parts or per-part headers, with extra weight when the target path is not a known upload handler.

Standard access logs do not record POST bodies, so this needs WAF or ModSecurity audit logs, reverse-proxy body capture, or a network sensor that parses HTTP bodies; access logs can still give the request size and content type for a coarse first pass. Sweep from Oct. 21, 2026, and set the size threshold per site from a week of normal multipart traffic. Exclude real upload endpoints that use the progress field by path, not by source address. Do not rely on disabling session.upload_progress or a WAF as the fix: Hunt.io notes the PHP advisory attributes the bug to out-of-memory bailout handling in general, and Cloudflare’s managed rules enabled on Oct. 21 did not block every attempt. A hit on a patched host is targeting only; a hit on an unpatched or end-of-life PHP host (Hunt.io’s priority targets ran PHP 5.x to 8.1) should be escalated, with memory and logs preserved before patching.

Hunt Lead Level: 2 (Pro)

ATT&CK: Initial Access → T1190 (Exploit Public-Facing Application)

Sources: “Hunting Leaked PHP2Shell RCE Across Open Directories (CVE-2026-109618, CVE-2026-109619)”, Hunt.io, Oct. 22, 2026, https://hunt.io/blog/php2shell-cve-2026-109618-109619-open-directories (source article)

Multipart POST Followed by PHP-FPM Memory-Exhausted Burst

Because the exploit works by forcing an out-of-memory bailout during request parsing, failed and successful attempts alike leave “Allowed memory size of N bytes exhausted” fatals in PHP-FPM or PHP error logs, and Hunt.io lists a burst of these from Oct. 21 onward as an attempt indicator. The mass-exploitation operator in the directories ran ten passes in just over an hour against up to 123 servers through about 97 proxies, so on a targeted host the pattern is a cluster of memory fatals that lines up with multipart POSTs, often from several different source addresses. The detection logic is a correlation that joins web access logs (multipart/form-data POST, large body or missing length) with PHP-FPM and PHP error logs on the same host within a few seconds, and alerts when the number of such pairs in a short window rises well above that host’s normal fatal rate.

This needs web access logs with method, content type, size and source address, PHP-FPM and PHP error logs, and accurate time sync, all in one SIEM. Build a 30-day per-host baseline of memory-exhausted fatals first, since buggy plugins and large legitimate uploads produce them, then back-test from Oct. 21 and run continuously. Because the mass operator rotated through proxies, count by destination host and request shape rather than by source address. Scope to unpatched and end-of-life PHP hosts first; Hunt.io notes version banners overstate exposure because distributions backport fixes, so check the actual package version rather than the X-Powered-By header. A burst on an unpatched host should be escalated: preserve logs and memory, then check for new PHP files in web roots and outbound connections to the infrastructure in the first lead. The correlation generalizes to other parser-level memory corruption attacks against interpreters.

Hunt Lead Level: 3 (Elite)

ATT&CK: Initial Access → T1190 (Exploit Public-Facing Application)

Sources: “Hunting Leaked PHP2Shell RCE Across Open Directories (CVE-2026-109618, CVE-2026-109619)”, Hunt.io, Oct. 22, 2026, https://hunt.io/blog/php2shell-cve-2026-109618-109619-open-directories (source article)

Published queries (Hunt.io HuntSQL, for measuring internet-wide PHP exposure on the Hunt.io platform rather than for detection in your own logs):

SELECT ip
FROM ip.current
WHERE http.headers.raw LIKE '%PHP%'
   OR http.headers.raw LIKE '%wp-json%'
   OR http.headers.raw LIKE '%laravel_session%'
   OR http.headers.raw LIKE '%19 Nov 1981%'

SELECT ip FROM ip.current WHERE http.headers.raw LIKE '%PHP/7.4%'
SELECT ip FROM ip.current WHERE http.headers.raw LIKE '%PHP/8.3%'

Hash Appendix

PHP2Shell tooling and Mirai-style botnet binaries

Hunt.io published no file hashes; it notes that two directories (41.223.30[.]7 and 157.230.117[.]70) held the same public tool with identical file hashes but does not list them, and it gives no botnet binary names or hashes. No hashes were pulled in from other sources for this report.

MD5s

(not available)  # no hashes published in the source article

SHA1s

(not available)  # no hashes published in the source article

SHA256s

(not available)  # no hashes published in the source article

References Appendix

• “Hunting Leaked PHP2Shell RCE Across Open Directories (CVE-2026-109618, CVE-2026-109619)”, Hunt.io, Oct. 22, 2026 (updated Oct. 28, 2026), https://hunt.io/blog/php2shell-cve-2026-109618-109619-open-directories (source article; vulnerability root cause, open-directory contents, target sets, botnet infrastructure, attempt signatures, JA4H, HuntSQL queries, exposure figures, recommendations)
• MITRE ATT&CK Enterprise technique pages linked above, MITRE, https://attack.mitre.org/