NadMesh Botnet Uses Shodan to Target AI and MCP Servers

A newly identified botnet called NadMesh is using Shodan data to locate exposed artificial intelligence services, automation platforms, and Model Context Protocol servers. It then places those systems at the front of its automated scanning and exploitation queue.

Researchers at QiAnXin XLab observed the Go-based malware spreading at scale in early July 2026. They named it NadMesh after finding the phrase “n4d mesh controller” in its source code.

The campaign targets more than AI processing power. NadMesh searches compromised systems for cloud credentials, Kubernetes tokens, Docker configurations, AI model access, and MCP tools capable of running commands or database queries.

How NadMesh uses Shodan to find AI services

NadMesh includes a reconnaissance component called ai_harvest.py. The script queries the Shodan API for internet-facing services associated with AI development, workflow automation, and local model hosting.

When the module finds a matching IP address, it adds the host to the botnet’s task queue with a high priority. This approach helps the operator focus on services that Shodan has already identified as reachable instead of scanning the entire internet without direction.

The harvester searches for several widely used platforms:

• ComfyUI
• Ollama
• n8n
• Open WebUI
• Langflow
• Stable Diffusion WebUI
• Gradio

Shodan does not carry out the attacks. It indexes information about internet-connected systems. NadMesh abuses that information to improve its target selection and increase the efficiency of its scanning operation.

NadMesh combines scanning, exploitation, and delivery

The botnet operates as a connected attack platform rather than a simple worm. Its controller distributes scanning tasks, records deployment results, collects stolen intelligence, and manages infected hosts through a web panel.

The controller listens on ports 80 and 8443 and uses HMAC-SHA256 authentication for bot communications. XLab found that it can distribute network ranges and port lists, receive beacon callbacks, and display campaign statistics through a management interface.

The operation follows five main stages:

1. Collect intelligence about exposed services.
2. Send tasks through the central controller.
3. Rescan networks that previously produced results.
4. Build obfuscated malware agents with different hashes.
5. Deliver the agent and establish persistence.

Which systems does NadMesh target?

NadMesh probes about 30 ports linked to AI applications, databases, container environments, web administration tools, and enterprise services. Its arsenal contains more than 20 exploitation methods, according to the researchers.

Despite its focus on AI and MCP infrastructure, observed attack traffic did not consist mainly of MCP exploitation. An independent review of the NadMesh campaign found that Docker API and Jenkins attacks represented the largest shares of the exploit attempts charted by XLab.

Many attack paths rely on exposed administrative functions, missing authentication, weak passwords, or dangerous configurations rather than a single software vulnerability.

Target	Observed attack method	Potential result
MCP servers	JSON-RPC tool calls to command or SQL functions	Remote command or database execution
Kubernetes	Malicious pod creation and hostPath mounts	Host access and token theft
Docker API	Privileged container creation	Container escape or host compromise
Redis	Unauthenticated configuration and file writes	Persistence or remote code execution
Jenkins	Exposed script console functions	Remote code execution
AI services	Prioritized scanning of exposed interfaces	Credential, model, or system access

Cloud credentials are a major target

After compromising a system, NadMesh inventories the host and searches for information that could unlock other infrastructure. The malware examines environment variables, configuration files, service accounts, and locally available AI resources.

The data collected from an infected system may include:

• AWS access keys and configuration files
• Amazon Bedrock credentials
• Kubernetes ServiceAccount tokens
• Docker configuration files and registry credentials
• Environment variables stored in .env files
• SSH session information
• Locally available Ollama and other AI models
• MCP tools such as execute_sql and execute_shell

This information can give attackers access to cloud accounts, internal clusters, private container registries, databases, or additional systems. It may therefore carry more value than the processing capacity of the original infected host.

The attacker’s dashboard claimed to contain 3,811 unique AWS keys. However, the dashboard displayed conflicting deployment and active-bot totals. Those figures should be treated as operator-controlled claims rather than independently confirmed victim counts, as noted in a detailed analysis of NadMesh activity.

Multiple persistence methods complicate removal

NadMesh creates several persistence mechanisms after infection. It can add an unauthorized SSH public key, place hidden copies of its agent in temporary directories, and create cron jobs that monitor or restore the malware.

Researchers identified agent copies in /dev/shm/.a, /var/tmp/.a, and /tmp/.a. They also found cron entries named /etc/cron.d/.sys_monitor and /etc/cron.d/.s. Removing only one file may leave another component capable of restoring the infection.

The malware uses Garble obfuscation, UPX compression, signature stripping, and random padding during its build process. These changes can give each generated agent a different file hash, limiting the value of detection rules that rely on one known sample.

NadMesh attempts to avoid honeypots

The botnet feeds successful results back into its scanning operation. Networks that produce useful targets receive more scans, while dangerous hosts discovered during earlier activity return to the queue for additional exploitation attempts.

NadMesh also tracks systems that repeatedly fail to produce a successful result. After ten unsuccessful deployment attempts, it can add an address to a suspected honeypot blacklist and stop spending resources on that target.

Public malware repositories provide limited supporting evidence of NadMesh samples in circulation. The MalwareBazaar NadMesh collection recorded tagged sightings beginning on July 18, 2026.

How administrators can reduce the risk

Organizations should first identify AI, automation, container, and MCP services that users have exposed to the public internet. Development tools often contain credentials or connect to powerful internal systems, even when teams deploy them only for testing.

1. Remove direct internet access from AI and MCP services unless it is essential.
2. Place administrative interfaces behind a VPN, firewall, or authenticated gateway.
3. Require strong authentication and multi-factor authentication where supported.
4. Disable anonymous Docker, Redis, Jenkins, and Kubernetes access.
5. Restrict MCP tools that can execute commands, shell scripts, or SQL queries.
6. Patch exposed software and review unsupported or outdated components.
7. Search systems for the known NadMesh persistence files and cron jobs.
8. Monitor outbound traffic for connections to known command-and-control infrastructure.
9. Revoke exposed cloud keys, tokens, and registry credentials after containing the host.
10. Review cloud audit logs for unauthorized use of stolen credentials.

If administrators find signs of NadMesh, they should isolate the affected host before issuing replacement credentials. Otherwise, a surviving persistence mechanism could steal the new credentials immediately.

NadMesh indicators of compromise

The XLab NadMesh report published one command-and-control IP address, one associated domain, and one sample SHA-1 hash.

Indicator type	Value
Command-and-control IP	209.99.186[.]235
Associated domain	cdnorigin[.]net
Sample SHA-1	31c69b3e12936abca770d430066f379ec1d997ec

Security teams can also review the NadMesh samples indexed by MalwareBazaar. A clean result for one hash does not rule out infection because the botnet can generate agents with different hashes.

FAQ