A botnet built for the AI stack
Researchers at QiAnXin's XLab have documented NadMesh, a Go-based botnet discovered in early July that goes after the tooling teams are standing up to run and orchestrate AI workloads. The list of targets reads like a survey of the self-hosted AI ecosystem: ComfyUI, Ollama, n8n, Open WebUI, Langflow, and Gradio. These are the interfaces engineers spin up to serve local models, chain automations, and prototype agents, often on cloud instances provisioned in a hurry. NadMesh uses Shodan to locate exposed instances at internet scale, then deploys agents that begin working the host for anything valuable. The campaign is a clear signal that the AI buildout has created a fresh and poorly defended attack surface.
What makes NadMesh notable is its focus. The malware is not chasing the compute on the box for cryptomining, which was the reflexive goal of earlier internet-scanning botnets. XLab noted that the operators care about the cloud credentials and Kubernetes cluster privileges reachable from the compromised system rather than the host itself. That shift in objective is the story. An exposed Ollama or n8n instance is rarely the crown jewel on its own. It is a doorway into the cloud account, the CI pipeline, and the container platform that surround it, and NadMesh is engineered to walk through that doorway and keep going.
How it harvests credentials
Once NadMesh lands on a host, it goes straight for the places credentials accumulate. XLab describes the malware extracting cloud keys from environment variables, Kubernetes service account tokens, and configuration files such as the AWS config directory, .env files, and the Docker config that stores registry credentials. These are the same locations legitimate tooling reads from, which is exactly why they are lucrative. Developers routinely leave long-lived keys in environment variables and dotfiles because it is convenient, and a self-hosted AI service running under a permissive service account inherits access to all of it. The botnet automates the collection that an attacker would otherwise perform by hand.
NadMesh also prioritizes Model Context Protocol tooling, specifically abusing the execute_command function that many MCP servers expose to let a model run shell commands. That is a meaningful escalation. MCP is becoming the connective layer between AI agents and real systems, and an execute_command primitive reachable over the network is effectively remote code execution with a friendly name. Beyond MCP, the malware works Docker APIs, Jenkins, Redis, and Telnet, giving it multiple footholds across a typical development environment. The design reflects an operator who understands how AI-adjacent infrastructure is actually wired together and where the soft joints between components tend to sit.
The flaws it chains
NadMesh does not rely on a single trick. XLab's analysis catalogs a mix of new and old vulnerabilities woven into the campaign, including CVE-2026-39987, a pre-authentication remote code execution flaw in the Marimo notebook tool, and CVE-2026-41176, an authentication bypass in rclone's remote control interface. It also reaches back into the archive for CVE-2022-22947 in Spring Cloud Gateway and CVE-2017-12611 in Apache Struts. Pairing fresh AI-ecosystem bugs with years-old enterprise classics is pragmatic, because unpatched Struts and Spring instances remain depressingly common in real estates and cost the operators nothing to try alongside the newer exploits.
The blend of exploits underscores a governance gap rather than a purely technical one. The AI tools in scope are frequently deployed outside the change-management and inventory processes that cover production systems, spun up by data science and platform teams moving fast. That shadow footprint is precisely what a Shodan-driven botnet feeds on, since assets nobody formally owns are assets nobody patches or monitors. NadMesh thrives in the space between what security teams think they run and what engineers have actually deployed. Closing that gap is an asset-visibility problem before it is a vulnerability-management one, and the two need to be solved in that order.
Scale and momentum
The figures suggest a campaign with real traction rather than a lab curiosity. NadMesh's operator dashboard claimed 3,811 unique AWS keys collected as of July 10, a haul that represents thousands of potential paths into cloud accounts belonging to organizations that likely have no idea they were touched. Stolen keys of this kind feed a downstream economy: some get used directly for resource abuse or data theft, while others are sold to actors who specialize in monetizing cloud access. A single leaked key with generous permissions can expose storage buckets, databases, and the ability to spin up infrastructure on the victim's bill.
XLab also observed roughly 139 distinct source IPs distributing NadMesh daily by early July, indicating an established and self-propagating footprint rather than a handful of test nodes. That distribution breadth means the scanning is persistent and geographically spread, so any exposed AI service is being probed continuously rather than occasionally. For enterprises, the practical implication is that an unsecured Ollama or Langflow instance left facing the internet will be found in short order. The margin for sloppy exposure has effectively vanished, and the assumption that an obscure internal tool will escape notice does not survive contact with automation operating at this scale.
What defenders should do now
The first move is visibility. Security teams should inventory every self-hosted AI and automation service across their cloud footprint, treating ComfyUI, Ollama, n8n, Open WebUI, Langflow, Gradio, and any MCP servers as internet-facing risks until proven otherwise. Anything reachable from the public internet without authentication needs to come down or go behind a gateway today. Because NadMesh hunts with Shodan, an external attack-surface scan of your own ranges is the fastest way to see what the adversary already sees. Assume that exposure equals discovery given the scanning volume documented here, and prioritize accordingly rather than waiting for an alert.
The second move is to shrink the payoff of a successful landing. Replace long-lived cloud keys in environment variables and dotfiles with short-lived, scoped credentials issued through the cloud provider's identity system, and run AI services under least-privilege service accounts that cannot reach the whole account. Lock down MCP execute_command exposure, disable it where it is not essential, and monitor for anomalous cloud API calls that would signal a stolen key in use. NadMesh is a preview of where this class of threat is heading, and the defensive fundamentals of identity hygiene and credential scoping are what blunt it before the next variant arrives.
