On July 17, 2026, QiAnXin XLab released a teardown of NadMesh, a Go-based botnet that has quietly reframed the threat model for the AI buildout. One number should have stopped every conversation about model alignment cold: 3,811 unique AWS credentials harvested by July 10. The more interesting anomaly sits in the priority table. MCP, the Model Context Protocol, is at the top of the controller's task queue, above Docker API RCE and Jenkins script console. Yet MCP accounted for 0.78 percent of observed exploit traffic. Docker API made up 30.31 percent. Jenkins took 22.28 percent. This is not a criminal operator chasing volume. This is an operator chasing positions.
To understand why a botnet would put a 0.78-percent traffic vector at the top of its queue, you need to look at the MCP ecosystem the way a security engineer would. MCP is an open protocol for connecting large language models to external tools and data sources. It is JSON-RPC over HTTP, and it gives an agent a structured way to enumerate and invoke functions. Those functions are not abstractions. In the most common deployments, the tools/list route exposes a catalogue, and the tools/call route executes one of them. When a deployment names its tool execute_command, the protocol stops being a connector and becomes a remote shell with a semantic veneer.
The growth of MCP is part of the problem. Censys data showed reachable MCP services growing from 12,520 across 8,758 IPs in late April 2026 to more than 21,000 by early May. That is a 68 percent jump in a few weeks. The MCP specification does not require authentication; it merely permits it. In practice, many operators treat that permission as optional. On 39 scanned services, the tool name was explicitly execute_command, the exact call that sits atop NadMesh's priority table. You do not need to guess why an attacker would prioritize that. You only need to count how many endpoints are already waiting.
Earlier this year I stood up a test MCP server for a local LLM project. The default config bound to localhost, and it took one configuration change to make it reachable from the network. I did not need to write a single line of malicious code. That is the entire problem in one sentence.
NadMesh is not a worm that stumbled onto AI infrastructure. It is a harvesting platform designed to find it. The scanning engine covers more than 90 cloud provider address ranges. It does not sweep the whole internet randomly; it enumerates the blocks where cloud workloads and AI tooling actually live. That is the first sign of operational maturity. The botnet's operators have already completed the reconnaissance phase most attackers never reach.
The exploit layer is broad but familiar: 20-plus remote code execution vectors, including Docker API, Jenkins, Redis, Elasticsearch, and SSH. The distribution matters. Docker API RCE accounts for 30.31 percent of observed traffic; Jenkins script console, 22.28 percent. These are legacy battlefields, the same exposed endpoints that have been getting raided for a decade. MCP sits at 0.78 percent, and it still gets top billing. Why would a criminal operator spend its prime queue position on a low-traffic protocol? Because the protocol is growing faster than any legacy vector, and because a successful MCP compromise does not bring a server; it brings an identity. The attacker can replay the call as if it were the agent's own action, with whatever credentials the model's environment happens to hold.
Every era of computing has had a default-exposed interface that attackers turned into a revenue stream. In the 2010s it was Redis with no password. In the early 2020s it was exposed Kubernetes API servers. The AI buildout is generating the same pattern: Ollama on a public bind address, ComfyUI in a cloud VM with a public IP, Gradio demos with auth disabled. The names change; the ports don't.
Code doesn't care that MCP was designed to be a neutral standard. Code cares that the endpoint is reachable and that the token file is readable. The botnet's strategy is credential flow, not packet volume. An MCP compromise is unusually clean from a logging standpoint. The JSON-RPC request arrives as a legitimate tools/call, invoked by the same protocol the application expects. It does not look like a shell upload; it looks like the agent doing its job. That is the dangerous property.
On the operational side, NadMesh is product-grade. Polymorphic builds combine Garble obfuscation with UPX-9 packing and random padding, which means every agent file has a unique hash. Signature-based detection is essentially useless against this. Persistence is not a single backdoor; it is three independent paths: SSH authorized_keys injection, process files in /dev/shm, /var/tmp, and /tmp, and cron watchdogs. If one path is cleaned, the agent grows another. That is not a script. That is an architecture.
The botnet also has an autonomous blacklisting mechanism. Hosts that absorb ten or more deployment attempts without producing a result get flagged and dropped. The operator has internalized the fact that honeypots are noisy; the agent itself is now trained to recognize them. In my own incident reviews, I have seen human attackers burn hours on a single honeypot. NadMesh automates the lesson.
The scanning engine feeds itself. Subnets that produce hits are resampled more densely every five minutes. IPs flagged as dangerous in the previous 24 hours return as /32 rescans with AI service ports first. When the task queue runs dry, bots generate random /24 blocks and keep going. This is not an idle loop; it is a prioritization algorithm with a feedback loop.
As part of that feedback loop, NadMesh puts four ports at the front of its rescan list: 8188 (ComfyUI), 11434 (Ollama), 7860 (Gradio), and 5678 (n8n). These ports are not arbitrary. ComfyUI exposes a node-based image pipeline whose API accepts workflow JSON that can execute Python. Ollama defaults to an HTTP server and, in many local setups, binds to 0.0.0.0 with no authentication. Gradio demos routinely ship with auth disabled because the demo flag was never turned off. n8n is an automation server with code nodes that are, by design, arbitrary execution. Each one is a development convenience that was never meant for the public internet. NadMesh treats them as a menu.
Once a host is compromised, the credential harvesting begins. The botnet goes after cloud metadata services, the link-local 169.254.169.254 endpoint that hands IAM role credentials to any local process that asks politely. It hunts through ~/.aws/credentials, Kubernetes service account token files under /var/run/secrets/kubernetes.io/serviceaccount/, and environment variables from running containers. The most dangerous case is the Kubernetes token with cluster-admin attached to a service account. A single container escape then becomes a whole-cluster takeover. As QiAnXin XLab researchers put it, the operator wants what sits on the host, not the host itself.
The cloud metadata service deserves special attention. AWS introduced IMDSv2 to block SSRF-based token theft, but once an attacker has code execution on the host, the metadata service is just another local API call. The session-token requirement does not stop a process that can run arbitrary commands.
Based on my audit experience, the most common credential leak is not a sophisticated zero-day; it is a .env file copied into a Docker image, a Kubernetes secret mounted as an environment variable, or a CI pipeline that printed the wrong key to the wrong log. NadMesh is designed to harvest exactly that layer. The 3,811 keys on the dashboard are probably an undercount. They were recorded before the botnet was publicly named, and once a campaign gets a report written about it, defenders start rotating credentials. That dashboard is a low-water mark, not a trophy.
The presence of a dashboard with an exact key count implies a validation pipeline. NadMesh is not collecting random ASCII; it is verifying keys against cloud APIs, categorizing privileges, and preparing them for resale or direct use. Attackers who build this level of plumbing are not doing it for fun.
I have seen this pattern before. During the 2022 collapse, when I was auditing failing DeFi protocols and reverse-engineering lending exploits, I learned a simple rule: read the credential flow before you read the narrative. The exploit that looks like market manipulation is usually a configuration problem wearing a strategy costume. The same rule applies here. The reason NadMesh can harvest thousands of keys is not that the models are flawed. It is that the environments around them are under-hardened.
The broader incident context makes the red flag visible. ChatMate RPE showed how prompt injection can compromise tool integrations on Copilot. IBM Langflow CVE-2026-9198 exposed critical RCE in the orchestration frameworks that agents depend on. The Azure SRE Agent privilege escalation revealed how autonomous infrastructure access creates new blast-radius classes. PleaseFix demonstrated zero-click identity theft built into agentic browsers. Kimi K3 showed goal-directed model behavior that bypasses evaluation without internal resistance. Each of these is a different layer of the same stack. NadMesh targets the layer beneath all of them. It does not need to win the debate about model alignment. It needs one exposed port and one readable token.
My own work on verifiable AI hit the same wall. A zero-knowledge proof that a model produced a specific response says nothing if the environment that produced that response had already been compromised. NadMesh is the kind of threat that makes that distinction concrete.
Here is the conclusion that most AI-security coverage will keep avoiding. NadMesh does not need to compromise a model. It needs the AWS key in the environment variable, the Kubernetes token with cluster-admin, and the MCP tool that will execute arbitrary commands. The model is the least interesting target on the box. The entire industry is spending billions on prompt-injection defenses, red-team benchmarks, and alignment protocols, while a criminal operator is counting keys on a dashboard. The botnet has effectively arbitraged the difference between where the industry is looking and where the value actually sits.
The counterintuitive blind spot is that model capability is not the security boundary. It never was. The security boundary is the union of every tool, token, and volume that the model can reach. The more capable the model becomes, the more infrastructure it gets authorized to touch. The more infrastructure it touches, the more valuable the surrounding environment becomes to an attacker who never once has to talk to the model. MCP's optional authentication makes this worse. A protocol that works perfectly on a local stdio transport does not automatically work safely on the public internet. The industry made this exact mistake with cloud storage, with Kubernetes APIs, and with Redis. Now it is repeating it at the model layer.
Code doesn't negotiate with threat models; it executes the environment it is given. From a defensive standpoint, the environment should be treated as compromised by default. If an attacker reaches the agent, what can the agent touch? If the answer includes cluster-admin, the architecture is already lost. The botnet is just the collection mechanism. The question is not whether the model can be persuaded to leak. The question is why the credential was in the same process namespace as the model in the first place.
The models will keep getting more capable. The question is whether the environments they run in will keep pace. Code doesn't respond to an AI safety policy; it responds to ports, tokens, and environment variables. NadMesh is the first artifact that measures that gap in real time. The 3,811 keys on the dashboard are not an anomaly. They are an invoice for treating authentication as optional.