If you run Ollama, ComfyUI, or n8n on a host with port 11434, 8188, or 5678 open to the public internet, you are now on a target list a Go-based botnet is actively sweeping. Researchers at QiAnXin’s XLab have been tracking a malware family they named NadMesh - after the “n4d mesh controller” string in its source - that appeared in early July 2026 and is hunting exposed AI services for cloud credentials rather than the host itself. According to The Hacker News, XLab’s sensors tracked distinct source IPs pushing NadMesh from near zero in late June to roughly 139 per day by the first week of July, and the operator’s own dashboard - screenshotted on July 10 - claims 3,811 unique AWS keys harvested.
What NadMesh actually does
NadMesh is not a cryptominer and not a ransomware installer. XLab’s writeup, as summarised by The Hacker News, characterises the operator’s goal in plain terms: “not the host itself, but the cloud credentials, Kubernetes cluster privileges” on it. The botnet is written in Go, uses Garble obfuscation with UPX -9 packing and random padding, and ships in five concurrent build versions with no two agents sharing a hash. It refreshes its scan queues from Shodan and reaches out to a command-and-control at IP 209.99.186[.]235 over the domain cdnorigin[.]net (sample SHA1 31c69b3e12936abca770d430066f379ec1d997ec).
The targets are the same self-hosted tools intelligibberish readers actually run. XLab’s scan list covers ComfyUI on port 8188, Ollama on port 11434, n8n on port 5678, Open WebUI, Langflow, and Gradio on port 7860. When the bot finds one, it pulls AWS keys from environment variables, ~/.aws/config, .env files, and ~/.docker/config.json, plus Kubernetes service account tokens, ~/.ssh/authorized_keys, and a small set of hidden paths under /dev/shm, /var/tmp, and /tmp for persistence. Triple persistence and cron-based re-entry keep the agent alive across reboots; targets that absorb ten deploys without yielding data are auto-blacklisted as suspected honeypots. The intel feed in the last 100 records XLab could read showed 47 credential hauls and 41 model inventories, with inventory tags carrying DeepSeek, GLM, and Kimi identifiers suffixed :cloud - suggesting the operator is also cataloguing what the host is running, not just what it can reach.
The MCP layer is what raises the stakes. The Hacker News reports that Model Context Protocol services sit at the top of NadMesh’s controller priority order, ahead of Kubernetes, Docker API, and Redis, and that the operator claims 12,100 MCP services as exploitable. The exploit path is a vanilla JSON-RPC tools/call to execute_command against a service that has not been locked down. No CVE is required because, by design, most MCP servers are not asking for authentication.
The MCP-shaped blast radius
How much of the public internet is sitting on that default-open MCP surface? A lot. Censys’s May 27, 2026 report on MCP servers on the internet counted 12,520 internet-accessible MCP services across 8,758 unique IP addresses in 56 countries and 425 ASNs as of April 28, 2026 - and more than 21,000 by May 6. The report frames the protocol’s default posture bluntly: “The protocol does not require authentication or authorization (by default).” Of the services Censys saw, 88.3 percent exposed at least one tool, with an average of 6.5 capabilities per service, and the “System Control” category alone covered 687 hosts running command-execution surfaces. The specific tool names show how thin the line is between “exposed tool” and “remote shell”: run_command (41 instances), execute_command (39), run_shell (6), exec_command (3), shell_exec (2).
Censys never tested those endpoints - the report is explicit: “Censys never attempted to execute any functionality on these servers.” NadMesh, by contrast, treats every reachable MCP service as a candidate remote shell. The same protocol that lets a local AI agent call a database query with no user interaction is the protocol that lets a botnet issue a JSON-RPC tools/call to execute_command and walk away with whatever the host can reach.
Censys’s framing of who is at fault is worth quoting in full: “Organizations appear to be deploying these systems faster than they are developing the operational understanding.” The same dynamic shows up in NadMesh’s dashboard, where headline counts (17,700 total deploys) sit next to contradictory funnel numbers (95,700 in 24 hours) and active-bot tiles that disagree with each other (16 vs. 12). The report on the botnet runs into the same gap: an operator that is scaling faster than it can keep its own metrics straight.
Why the local-AI audience is exposed
The services NadMesh scans are not obscure enterprise tools. Ollama is the default local-LLM server on thousands of developer laptops and home labs; ComfyUI is the standard node-based UI for Stable Diffusion and the FLUX/SDXL variants readers run locally for image generation; n8n is a self-hostable automation platform that the intelligibberish audience runs in Docker; Open WebUI, Langflow, and Gradio are the standard chat and app front-ends for the same stack. XLab’s sensor view of actual NadMesh exploit traffic tells the rest of the story: 30.31 percent of attempts hit Docker containers’ API for remote code execution, 22.28 percent went after Jenkins, 10.36 percent brute-forced Telnet, 8.29 percent went after Redis, and 0.78 percent landed on the mcp_cmd_execute path that NadMesh is explicitly built around.
There is also a precedent. The Hacker News notes that a different operator targeted exposed ComfyUI for Monero and Conflux cryptomining and Hysteria proxy resale as recently as April 2026; three months later, NadMesh sweeps a wider net, but exposed ComfyUI and Docker on port 2375 remain on both target lists. The earlier operator wanted the GPU; NadMesh wants what the box can log into. The shift from “use the host” to “log in with what the host has” is the change that matters for any reader running these tools on a VPS or a homelab with a public IP.
What This Means
If you self-host Ollama, ComfyUI, Open WebUI, Langflow, Gradio, or n8n, the practical move is the same one local-AI operators should already be doing: bind these services to localhost or a private network, put them behind a reverse proxy with authentication, and never expose port 11434, 8188, 7860, or 5678 to the public internet. A single exposed instance is enough to put your AWS keys, your Kubernetes service-account tokens, and your ~/.ssh/authorized_keys on a target list that an active botnet is sweeping this month.
For teams running these tools inside a cloud account, the secondary risk is lateral. A NadMesh-style compromise does not stop at the host that ran ComfyUI; it walks into whatever IAM role, cluster, or git remote that host can reach. The architectural lesson is the one Censys already named: the protocol default is no authentication, and the operational default for self-hosted AI services cannot keep being “exposed to the internet with no auth in front of it” if the same protocol is now actively being scanned for credential theft.
The Bottom Line
NadMesh is a Go-based botnet, reported by QiAnXin XLab, that is sweeping the public internet for exposed Ollama, ComfyUI, n8n, Open WebUI, Langflow, and Gradio instances - including MCP servers with command-execution tools - and stealing AWS keys and Kubernetes tokens instead of mining the host.