New NadMesh Botnet Hunts Exposed AI Services for Cloud Keys and Kubernetes Tokens
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2017-12611 | In Apache Struts 2.0.0 through 2.3.33 and 2.5 through 2.5.10.1, using an unintentional expression in a Freemarker tag instead of string literals can lead to a R In Apache Struts 2.0.0 through 2.3.33 and 2.5 through 2.5.10.1, using an unintentional expression in a Freemarker tag instead of string literals can lead to a RCE attack. NVD description · AI analysis pending | 9.8 | 87% | PoC |
| — | |
| CVE-2022-22947 | Unauthenticated RCE in VMware Spring Cloud Gateway CVE-2022-22947 is a code injection (Spring Expression Language injection) flaw in VMware Spring Cloud Gateway that allows arbitrary remote code execution when the Gateway Actuator endpoint is enabled, exposed, and unsecured. A remote, unauthenticated attacker can send a maliciously crafted request (typically a crafted POST to the gateway actuator routes endpoint) that is evaluated as code, letting the attacker run arbitrary commands on the host. The CVSS 3.1 score is 10.0 (critical) because exploitation is network-based, requires no privileges or user interaction, and impacts confidentiality, integrity, and availability beyond the vulnerable component. All Spring Cloud Gateway deployments prior to 3.1.1/3.0.7 are affected, along with Oracle products that embed the component, including Commerce Guided Search and multiple Oracle Communications Cloud Native Core functions. Exploitation is confirmed: the flaw was added to CISA's Known Exploited Vulnerabilities catalog on 2022-05-16, EPSS puts the 30-day exploitation probability at 98.3% (100th percentile), public PoC exploits exist, and related reporting describes botnets adding Spring Cloud Gateway exploits to their attack tooling. Do: Upgrade Spring Cloud Gateway to 3.1.1 or later, or to 3.0.7 or later on the 3.0.x line, per VMware's advisory, and apply the relevant Oracle Critical Patch Update for affected Oracle Commerce Guided Search and Communications Cloud Native Core products. If you cannot patch immediately, disable or restrict the Gateway Actuator endpoint so it is not reachable over the network without authentication. Scan for exposed gateway actuator endpoints and review hosts for signs of command execution; this flaw is on CISA's KEV list, which requires applying updates per vendor instructions. | 10.0 | 98% | KEV PoC ×2 |
| large≈ tens of thousands of deployments plausibly affected worldwide, with only the subset exposing the actuator endpoint unauthenticated directly exploitable from… | |
| CVE-2026-39987 | Unauthenticated Remote Code Execution in Marimo Python Notebook Marimo, a reactive Python notebook, contains an unauthenticated remote code execution flaw (CVE-2026-39987, CWE-306; CVSS 4.0: 9.3 Critical) because its terminal WebSocket endpoint /terminal/ws skips authentication entirely. Unlike other WebSocket endpoints such as /ws, which call validate_auth(), /terminal/ws only checks the running mode and platform support before accepting connections, so any unauthenticated attacker who can reach the server can obtain a full PTY shell and execute arbitrary system commands on the host. All marimo deployments running versions prior to 0.23.0 are affected, with internet-exposed instances at greatest risk. Exploitation is confirmed in the wild: the flaw was added to CISA's KEV catalog on 2026-04-23, public PoCs exist, and reporting shows it was exploited within roughly 10 hours of disclosure, with observed post-exploitation activity involving LLM agents. EPSS assigns a 98.9% probability of exploitation within 30 days (100th percentile). Do: Upgrade marimo to 0.23.0 or later; until patched, restrict access to the /terminal/ws WebSocket endpoint by binding the notebook to localhost, a VPN, or an authenticating reverse proxy. Identify whether any marimo instances are internet-exposed and review logs for connections to /terminal/ws and unexpected shell or process spawns, given reports of LLM-agent-driven post-exploitation on compromised instances. As a KEV entry (added 2026-04-23), this requires federal agencies to apply the vendor fix or mitigations per BOD 22-01 timelines. | 9.3 | 99% | KEV PoC ×4 |
| moderatelikely tens of thousands of users, with directly internet-exposed marimo servers plausibly in the low thousands | |
| CVE-2026-41176 | Unauthenticated Access Control Bypass in Rclone RC options/set Endpoint Rclone's remote control (RC) API exposes the `options/set` endpoint without an authentication requirement, and because that endpoint can mutate global runtime configuration — including the RC option block itself — an unauthenticated attacker can enable `rc.NoAuth` and thereby disable the authorization gate on many other RC methods. The flaw affects rclone starting in version 1.45.0 and in all versions prior to 1.73.5, but only on RC servers that are reachable over the network and started without global HTTP authentication. With a single unauthenticated request an attacker gains access to sensitive administrative functionality, including configuration and operational RC methods that normally require authorization. Anyone running an affected rclone version with an RC server exposed without HTTP authentication is affected; rclone users who do not enable the RC feature are not impacted. Exploitation has not been confirmed in the wild (not in CISA KEV), but a public proof of concept exists and EPSS assigns a 32.7% probability of exploitation within 30 days (98th percentile). Do: Upgrade to rclone 1.73.5 or later, prioritizing any RC server reachable from untrusted networks. Until patched, restrict the RC listener to localhost or trusted networks and enable global HTTP authentication on the RC server. Review RC logs for unexpected unauthenticated calls to options/set, given the elevated 32.7% EPSS likelihood of exploitation. | 9.2 | 33% | PoC |
| moderate≈ thousands of network-exposed rclone RC servers without HTTP authentication (order-of-magnitude estimate) |
Indicators of compromiseauto-extracted · verify before use · export allAll →
| Type | Indicator | Context |
|---|---|---|
| domain | cdnorigin.net | XLab's indicators are a C2 at 209.99.186[.]235, the domain cdnorigin[.]net, and one agent sample, SHA1 31c69b3e12936abca770d430066f3 |
| sha1 | 31c69b3e12936abca770d430066f379ec1d997ec | 235, the domain cdnorigin[.]net, and one agent sample, SHA1 31c69b3e12936abca770d430066f379ec1d997ec. The Hacker News covered a different operator working the s |
Full article1,186 words · extracted from thehackernews.com · click to collapse
A Go botnet called NadMesh turned up in early July hunting exposed AI services, and the operator's own dashboard claims 3,811 unique AWS keys.
A Shodan harvester keeps the scan queue stocked with ComfyUI, Ollama, n8n, Open WebUI, Langflow, and Gradio: the image generators, local model runners, and workflow builders that teams stand up fast and firewall late.
The intel feed behind that counter shows 47 credential hauls and 41 model inventories in its last 100 records. Those inventories carry DeepSeek, GLM, and Kimi identifiers tagged :cloud, which suggests that what the bots catalogue reaches past the box itself.
QiAnXin's XLab published a report on Friday, named the malware after the "n4d mesh controller" string in its source, and screenshotted the panel. The figures on it are the operator's own, captured July 10, and they do not agree with each other.
A counter reading 17,700 total deploys sits above a funnel claiming 95,700 in the past 24 hours. One tile says 16 active bots; the next says 12. The credential number is at least the one it states twice. XLab's own sensors give an outside measure, and it is not a bot count either: distinct source IPs pushing NadMesh sat near zero through late June, then went vertical in the first week of July to around 139 a day.
What a bot ships home is cloud keys pulled out of environment variables, k8s service account tokens, and the contents of ~/.aws/config, .env, and ~/.docker/config.json.
The researchers put it plainly: the operator is after "not the host itself, but the cloud credentials, Kubernetes cluster privileges" on it. Model access and callable MCP tools round out the list.
MCP heads the controller's priority order for exploitation, above Kubernetes, Docker API, and Redis, and the vector XLab records beside it is a JSON-RPC tools/call to execute_command. No CVE is attached to that line, and the report does not claim one.
MCP's first specification put authentication outside the core protocol entirely, and the authorization flow added in March 2025 is still optional in the spec's own words. Plenty of deployments skip it. Censys counted 12,520 reachable MCP services across 8,758 IP addresses as of April 28, more than 21,000 by May 6, and roughly 90 advertising a tool that runs commands.
On 39 of those, the tool was named execute_command, the exact call at the top of NadMesh's table. The botnet's own MCP counters do not reconcile: 12,100 MCP services listed as exploitable, 21 MCP vulnerabilities overall, and none at all among the 100 intel records on screen.
Then there is what XLab actually watched it throw. The firm charted the exploit traffic it observed, and docker_containers_api_rce takes 30.31% of it, jenkins_scripttext_rce another 22.28%. Telnet weak passwords take 10.36%, Redis 8.29%.
mcp_cmd_execute is on the chart, so the vector is in XLab's observed traffic, but it sits in the unlabeled tail below the smallest slice anyone bothered to label, at 0.78%. The chart's labels do not match the controller's own status strings, so it is XLab's sensor view of attempts, not the operator's success ledger.
So the AI targeting is real at the intake and in the loot, and most of the exploit traffic still goes to Docker sockets and Jenkins consoles.
The scanning feeds itself. Subnets that produce hits get resampled more densely every five minutes; IPs flagged dangerous in the last 24 hours come back every quarter hour as /32 rescans with the AI ports first; a full sweep drags everything marked dangerous in the last seven days back to the top.
Any target that absorbs ten deployment attempts without ever returning a result is auto-blacklisted as a suspected honeypot. XLab takes that as a sign the author knows researchers are watching. If the queue runs dry, bots generate a random /24 and keep going.
Five build versions run concurrently, eleven bots on 33.8-GO-TITAN, and the stragglers back on 30.0. A canary endpoint stages new builds to a slice of the fleet, 5,448 responses served, and 84,024 null. A funnel tracks tasks down through deploys to live hosts.
The panel's own footnote is the tell: success is scored on an outcome allowlist that explicitly excludes the Ollama and AWS harvest. The operator's scoreboard does not count the thing the operator is taking.
Removal is built to fail. The agent persists in three ways at once, so pulling one leaves the others to bring it back. Every build goes through Garble obfuscation, UPX -9 packing, and random padding, which means no two agents share a hash. The published sample hash will catch that one build and miss the rest.
If You Run Any of This
Most of what NadMesh throws is aimed at exposed services and admin functionality left callable: an open Docker API on 2375, a Jenkins script console, unauthenticated Redis, weak Telnet, and SSH passwords. No patch closes any of those.
Get them behind auth or off the public internet, starting with the four ports the rescan job puts first: 8188 (ComfyUI), 11434 (Ollama), 7860 (Gradio), and 5678 (n8n).
There is a patch queue too, and it is not all ancient. The chart includes CVE-2026-39987, the pre-auth RCE in Marimo notebooks before 0.23.0. CISA put it on KEV in April after it was exploited within hours of disclosure.
Next to it sits CVE-2026-41176, which lets an unauthenticated caller flip rc.NoAuth on rclone RC servers from 1.45.0 up to 1.73.5 that were started without HTTP auth. rclone configs are cloud credentials. Older entries need their conditions checked before you panic: CVE-2022-22947 at 6.48% only bites if the Spring Cloud Gateway Actuator endpoint is enabled and exposed unsecured, and CVE-2017-12611 at 4.15% is the Struts Freemarker tag flaw.
Then check the drop paths:
- ~/.ssh/authorized_keys, for keys nobody remembers adding
- /dev/shm/.a, /var/tmp/.a, /tmp/.a
- /etc/cron.d/.sys_monitor, /etc/cron.d/.s
If any of that turns up, isolate the host and revoke every credential it could see immediately: AWS keys, cluster tokens, .env contents, registry logins. Revoking is not rotating. Pull the persistence before you issue replacements, or the new keys go the way of the old ones.
Then review where the old ones were used while they were live. XLab's indicators are a C2 at 209.99.186[.]235, the domain cdnorigin[.]net, and one agent sample, SHA1 31c69b3e12936abca770d430066f379ec1d997ec.
The Hacker News covered a different operator working the same target class in April: Censys had found it farming exposed ComfyUI for the GPU, Monero, and Conflux mining, plus a Hysteria proxy node for resale. Three months on, NadMesh sweeps a far wider net, but exposed ComfyUI and Docker on 2375 sit on both target lists.
What changed is the payoff: the April operator wanted the GPU, and NadMesh wants what the box can log into. Censys ended its MCP census with a guess at the least-bad outcome for all those exposed shell tools, the host winding up "part of some future botnet or abuse infrastructure." That was May 27. XLab published a botnet with mcp_cmd_execute in its exploit chart seven weeks later.
Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
Text extracted automatically; images, tables and formatting may be missing. Original: https://thehackernews.com/2026/07/new-nadmesh-botnet-hunts-exposed-ai.html