A new botnet discovered in early July 2026 demonstrates a disturbing evolution in threat actor tooling: a commercial-grade, productized attack platform explicitly designed to compromise AI workloads and Model Context Protocol (MCP) servers. Dubbed "NadMesh" after its controller component ("n4d mesh controller"), this Go-based botnet integrates scanning, exploitation, credential theft, and AI service intelligence collection into a unified mesh infrastructure.

Unlike opportunistic worms, NadMesh behaves like a managed service with operational metrics, conversion funnels, and honeypot avoidance — indicating a threat actor focused on ROI rather than vandalism.

What Happened

Security researchers at QiAnXin (qianxin) published a technical analysis of NadMesh on July 10, 2026, revealing a botnet that has been iteratively developed and actively deployed against cloud and AI infrastructure. The name derives from the controller binary's self-identification string: "n4d mesh controller."

NadMesh is written in Go and operates as a distributed mesh of attacker-controlled VPS nodes. Each node runs a controller that coordinates large numbers of bots through HTTP APIs, providing a web panel, statistics dashboard, and canary-style updates. The architecture supports continuous scanning, task distribution, and automated exploit deployment across more than 20 distinct vulnerability vectors.

The botnet's primary innovation is its explicit targeting of the emerging AI and MCP ecosystem. Its default port list includes 8188 (ComfyUI), 11434 (Ollama), 5678 (n8n), and 7860 (Gradio) — all default ports for popular AI/ML serving frameworks. An auxiliary script, ai_harvest.py, actively queries Shodan for these signatures and feeds high-priority /32 scan tasks to the controller.

Why This Matters to Developers

The rise of AI-assisted development and local LLM serving has created a new attack surface that traditional vulnerability scanners miss. Developers increasingly run Ollama, ComfyUI, n8n, Gradio, Langflow, and Open WebUI on cloud instances or local machines exposed to the internet — often without authentication, rate limiting, or network segmentation.

NadMesh exploits this gap systematically. Its exploit chains include:

• MCP JSON-RPC tool abuse — Calling execute_command and similar privileged tools exposed via Model Context Protocol endpoints
• Kubernetes API abuse — Leveraging pods with hostPath mounts for container escape
• Docker API misuse — Launching containers with host networking and auto-restart for persistence
• Redis CONFIG SET + SAVE — Planting cron-driven persistence via Redis misconfiguration
• Classic web app exploits — Elasticsearch, Jenkins script console, Spring Cloud Gateway SpEL injection, code-server, Airflow, Superset, XXL-Job, and WebLogic deserialization bugs

These are not theoretical — the controller models multi-step "chains" that combine initial access, privilege escalation, and persistence into automated workflows.

Technical Breakdown

Architecture Overview

┌─────────────┐ HTTP API ┌─────────────┐ │ Controller │◄─────────────────►│ Bots │ │ (VPS mesh) │ Tasks / Intel │ (Compromised)│ └─────────────┘ └─────────────┘ │ │ ▼ ▼ ┌─────────────┐ ┌─────────────┐ │ Web Panel │ │ ai_harvest │ │ Stats/Logs │ │ (Shodan → │ │ Canary Upd. │ │ Priority │ └─────────────┘ │ Tasks) │ └─────────────┘

Scanning Engine

The controller seeds bots with over 90 cloud provider CIDR ranges (AWS, GCP, Azure, Alibaba Cloud, DigitalOcean, etc.). Bots request task batches via /api/task/pull, receive CIDR blocks and port sets, and scan using a standard 30-port list covering web services, Kubernetes (6443, 10250), Docker (2375, 2376), databases, monitoring, and AI endpoints.

When the central queue empties, bots fall back to generating random /24 ranges, ensuring continuous expansion without human intervention.

Exploitation Framework

The controller maintains a library of exploit "chains" — each chain models a multi-step path from initial access to persistent foothold. The abstraction allows the operator to add new vectors without rewriting bot logic. Notable chains include:

Chain Name	Target	Technique
mcp-tools	MCP servers	JSON-RPC execute_command / read_resource
k8s-hostpath	Kubernetes API	Pod with hostPath mount → host filesystem access
docker-host	Docker API	Container with hostNetwork: true, restart: always
redis-cron	Redis	CONFIG SET dir /etc/cron.d + SAVE
jenkins-console	Jenkins	Script Console Groovy execution
spring-gateway	Spring Cloud Gateway	SpEL injection via Route definition
weblogic-deser	WebLogic	T3/IIOP deserialization gadgets

Honeypot Avoidance

NadMesh implements a conversion funnel metric: scans → exploit attempts → successful deployments → persistent footholds. Hosts that repeatedly accept deployments without yielding results are flagged as suspected honeypots and automatically blocked, reducing wasted effort on researcher-controlled environments.

This self-optimizing behavior suggests the operators treat the botnet as a commercial product, measuring and improving "exploit conversion rates" over time.

Indicators of Compromise

IOC Type	Indicator	Context
C2 IP	209.99.186[.]235	Primary NadMesh controller / VPS hosting mesh scanner, HTTP API (/api/*, /panel)
C2 Domain	cdnorigin[.]net	CDN-style distribution host for agent binaries and updates, including disguised assets via paths like /cdn/<binaryToken>/assets/img.bin

IP addresses and domains are defanged. Re-fang only within controlled threat intelligence platforms (MISP, VirusTotal, SIEM).

Affected Systems

Any internet-exposed service running on the following default ports is actively targeted:

• 8188 — ComfyUI (Stable Diffusion web UI)
• 11434 — Ollama (local LLM serving)
• 5678 — n8n (workflow automation)
• 7860 — Gradio (ML demo sharing)
• 6443 — Kubernetes API server
• 2375/2376 — Docker daemon API
• 6379 — Redis
• 9200 — Elasticsearch
• 8080/8081/8443 — Jenkins, code-server, Spring Cloud Gateway, Airflow, Superset, XXL-Job, WebLogic

Developers running these services on public IPs without authentication, network segmentation, or TLS are primary targets.

Mitigation and Hardening

Immediate Actions

1. Inventory AI/ML workloads: Identify all instances running Ollama, ComfyUI, Gradio, n8n, Langflow, Open WebUI, or MCP servers
2. Enforce authentication: Add auth proxies (OAuth2-Proxy, Authelia) or built-in auth where available
3. Network segmentation: Move AI services to private subnets; expose only via VPN or zero-trust access (Tailscale, Cloudflare Tunnel)
4. Disable unused APIs: Turn off Docker API, Kubernetes API, Redis remote access unless strictly required
5. Patch known CVEs: Ensure Kubernetes, Jenkins, Spring, WebLogic, and other components are on supported versions
6. Monitor for IOCs: Block outbound connections to 209.99.186.235 and cdnorigin.net

Secure Configuration Examples

Ollama with authentication (via reverse proxy):

Docker daemon — disable remote API or restrict to localhost:

MCP server — require authentication on all tools:

Detection Guidance

Sigma: NadMesh AI Service Scanning Activity

Suricata: NadMesh C2 Communication

YARA: NadMesh Bot Binary Detection

Frequently Asked Questions

Q: Is NadMesh a worm or a botnet? A: It's a botnet with worm-like scanning capabilities. Bots don't self-propagate laterally post-exploitation; instead, they report back to the controller which tasks new targets. The "mesh" refers to the controller-to-bot coordination layer.

Q: What makes NadMesh different from Mirai or Mozi? A: Traditional IoT botnets target weak credentials and known CVEs in embedded devices. NadMesh is purpose-built for cloud and AI infrastructure — it targets Kubernetes, Docker, MCP, and ML serving frameworks, and includes operational metrics (conversion funnels, honeypot detection) typical of commercial attack platforms.

Q: Does NadMesh exploit zero-days? A: The QiAnXin analysis indicates all 20+ vectors are known vulnerabilities or misconfigurations (N-day exploits and configuration weaknesses). The novelty lies in the automation, targeting focus, and productization — not in undisclosed vulnerabilities.

Q: How can I check if my AI servers are compromised? A:

• Review authentication logs for Ollama/ComfyUI/Gradio for unknown source IPs
• Check for unexpected containers with hostNetwork: true or hostPath mounts
• Scan for cron jobs in /etc/cron.d/ written via Redis
• Monitor outbound connections to 209.99.186.235 or cdnorigin.net
• Run the YARA rule above on suspicious binaries

Q: What is the Model Context Protocol (MCP) and why is it targeted? A: MCP is an open protocol standardizing how applications provide context to LLMs. MCP servers expose tools (file access, command execution, database queries) via JSON-RPC. When exposed without authentication, these tools become direct RCE vectors — exactly what NadMesh's mcp-tools chain exploits.

Key Takeaways

• NadMesh is a productized attack platform targeting AI/ML infrastructure, not a one-off worm
• 20+ exploit chains cover Kubernetes, Docker, Redis, MCP, Jenkins, Spring, WebLogic, and ML serving frameworks
• AI/ML default ports (8188, 11434, 5678, 7860) are explicitly prioritized — developers running these services on public IPs are primary targets
• Honeypot avoidance and conversion metrics indicate commercial operator mindset
• No authentication on MCP tools = instant RCE — treat MCP endpoints like any other privileged API
• Detection is feasible via network IDS (Suricata), endpoint logging (Sigma), and binary analysis (YARA)

Conclusion

The emergence of NadMesh signals a shift: threat actors are building dedicated tooling for the AI infrastructure boom. Developers and platform engineers must treat local LLM servers, MCP endpoints, and workflow automation tools as critical attack surfaces — not development conveniences. Network segmentation, strong authentication, and continuous vulnerability management for AI workloads are no longer optional.

---

Sources:

• QiAnXin XLab: NadMesh Botnet Analysis: A Product-Grade Threat for the AI Service Era
• CyberPress: NadMesh Botnet Targets AI and MCP Servers With 20+ Remote Code Execution Vectors