Security researchers are observing active scanning campaigns targeting exposed Model Context Protocol (MCP) servers, unauthenticated LLM endpoints, and AI assistant credentials across the internet. The attacks exploit fundamental trust assumptions in MCP's architecture, enabling credential theft, data exfiltration, and unauthorized AI compute consumption.

What Happened

In mid-July 2026, threat intelligence feeds began detecting coordinated reconnaissance against MCP-enabled infrastructure. Attackers are scanning for:

• Exposed MCP servers listening on default ports (typically 8080-8090, 3000-3010) without authentication
• AI assistant configuration files (.cursor/mcp.json, claude_desktop_config.json, .vscode/mcp.json) containing API keys and server credentials
• Unauthenticated LLM endpoints -- Ollama, vLLM, TGI, and local model servers bound to 0.0.0.0
• MCP server registries and discovery endpoints leaking server metadata

The scanning activity correlates with the rapid adoption of MCP across Cursor, Claude Desktop, Windsurf, Zed, VS Code Copilot, and JetBrains IDEs. As developers connect dozens of third-party MCP servers to their AI coding assistants, the attack surface has expanded dramatically.

Why This Matters to Developers

If you use AI coding assistants with MCP servers, you are likely exposed. The Model Context Protocol was designed for local-first, trusted environments -- not for internet-exposed services. Yet many developers:

• Run MCP servers in containers bound to 0.0.0.0 for remote access
• Store API keys, database credentials, and OAuth tokens in plaintext config files
• Connect to unverified third-party MCP servers from public registries
• Disable authentication for "convenience" during development

This creates a perfect storm: attackers can discover your MCP endpoints, extract credentials from configuration files, and pivot to your cloud resources, source code repositories, and production databases.

Vulnerability Details: The MCP Trust Model Failure

MCP's architecture introduces three critical trust boundaries that attackers routinely violate:

1. Tool Poisoning Attacks (TPA)

Malicious MCP servers embed hidden instructions in tool descriptions that are visible to the LLM but hidden from users. When you invoke a seemingly benign tool like add(a, b), the tool description may instruct the model to:

The LLM faithfully executes these hidden instructions, exfiltrating your MCP configuration (which contains credentials for other MCP servers) and SSH keys. Invariant Labs demonstrated this against Cursor in April 2026, showing complete credential theft via a single poisoned tool.

2. Rug Pull Attacks

MCP servers can mutate their tool descriptions after user approval. You approve a safe-looking tool on Day 1; by Day 7, the server silently updates the description to include data exfiltration instructions. The client (Cursor, Claude Desktop, etc.) does not re-validate tool descriptions on each invocation.

3. Cross-Server Shadowing

When multiple MCP servers connect to the same client, a malicious server can override or intercept calls to trusted servers. In Invariant Labs' demonstration, a malicious add tool rewrote the behavior of a trusted send_email tool, redirecting all emails to the attacker's address -- even when the user explicitly specified a different recipient.

4. Unauthenticated LLM Endpoint Abuse

Beyond MCP, attackers scan for exposed inference servers:

• Ollama (port 11434) -- often runs with no auth, allowing model theft and compute hijacking
• vLLM/TGI (ports 8000, 8080) -- production inference servers frequently deployed without TLS or auth
• LocalAI, LM Studio, Text Generation WebUI -- developer tools exposed to LAN/internet

These endpoints allow attackers to run inference at your expense, extract fine-tuned models, and inject prompts into your AI workflows.

Impact Assessment

Impact Vector	Severity	Description
Credential Theft	Critical	MCP config files contain API keys for GitHub, AWS, GCP, databases, Slack, Notion, Linear, and dozens of other services
Source Code Exposure	Critical	MCP servers with filesystem access can read entire repositories, including .env, secrets.yaml, and private keys
Supply Chain Compromise	High	Poisoned MCP servers can inject malicious code into your builds via AI-assisted coding
Compute Theft	Medium	Attackers use your GPU/CPU for inference, cryptomining, or DDoS amplification
Lateral Movement	High	Stolen cloud credentials enable pivot to production environments

Affected Systems

You are at risk if you:

• Use Cursor, Claude Desktop, Windsurf, Zed, VS Code Copilot, or JetBrains AI with any third-party MCP server
• Run MCP servers in Docker/Kubernetes without network policies or authentication
• Have ~/.cursor/mcp.json, ~/Library/Application Support/Claude/claude_desktop_config.json, or similar config files with plaintext secrets
• Expose Ollama, vLLM, or other inference servers to non-localhost interfaces
• Install MCP servers from public registries (glama.ai, mcp.so, pulse.mcp.com) without code review

Mitigation & Patching: Immediate Actions

1. Audit Your MCP Configuration Files

Rotate every credential found in these files immediately.

2. Enable Authentication on All MCP Servers

Most MCP servers support token-based auth. Configure it:

Server-side, enforce the token:

3. Bind MCP Servers to Localhost Only

Never bind to 0.0.0.0. Use SSH tunnels for remote access:

4. Containerize with Dropped Capabilities

Run with:

5. Use an MCP Gateway/Proxy

Tools like Docker MCP Catalog, MCPSafe, HyprMCP, and Invariant Guardrails provide:

• Centralized authentication and authorization
• Tool description validation (detects poisoning/rug pulls)
• Cross-server isolation (prevents shadowing)
• Audit logging of all tool invocations

Example Docker MCP Gateway config:

6. Scan Your MCP Servers Before Connecting

7. Secure Inference Endpoints

Detection: How to Tell If You're Compromised

Indicators of Compromise

1. Unexpected tool invocations in your AI client logs -- tools you didn't call executing actions
2. Unknown MCP servers appearing in your config -- supply chain compromise
3. Abnormal API usage spikes on GitHub, AWS, or other integrated services
4. SSH keys or config files accessed at unusual times (check last and file access times)
5. Container logs showing connections from unknown IPs to MCP ports

Detection Commands

Frequently Asked Questions

Q: Is MCP inherently insecure?

A: MCP's design prioritizes flexibility over security. The protocol can be secure, but the default configurations and client implementations are not. Treat MCP like you would SSH -- never expose it directly, always use keys/auth, and audit regularly.

Q: Can I use MCP servers safely without a gateway?

A: Yes, if you: (1) run servers locally only, (2) use env vars for secrets, (3) review server code before installing, (4) pin server versions, (5) limit each server's permissions to the minimum necessary.

Q: Which MCP clients have the best security?

A: As of July 2026: Docker MCP Toolkit (gateway + catalog), Cursor (improving tool confirmation UI), Claude Desktop (basic auth support). None are fully secure by default -- you must configure them.

Q: How do I verify an MCP server isn't malicious?

A:

1. Scan with MCPSafe or Invariant MCP-Scan
2. Review the source code (avoid closed-source servers)
3. Check for os.system, subprocess, eval, exec in the code
4. Verify tool descriptions don't contain hidden <IMPORTANT> blocks
5. Run in a container with --read-only --cap-drop=ALL --network=none

Q: What about the official MCP servers from Anthropic/Microsoft/GitHub?

A: The official servers (GitHub, Slack, Filesystem, PostgreSQL, etc.) are well-maintained and generally safe. The risk comes from third-party servers and how you configure them. Still, apply the same hardening.

Q: Can attackers scan my local MCP servers from the internet?

A: Only if you've exposed them via port forwarding, ngrok, Cloudflare Tunnel, or binding to 0.0.0.0. Localhost-bound servers are not directly scannable, but malware on your machine or a compromised browser extension could access them.

Key Takeaways

1. MCP exposure is the new .git exposure -- config files with credentials are being actively scanned and harvested
2. Tool poisoning is real and practical -- hidden instructions in tool descriptions bypass user consent
3. Cross-server attacks amplify risk -- one malicious server compromises all connected servers
4. Default configurations are insecure -- localhost-only binding, auth tokens, and secret management are opt-in
5. Containerization + Gateway = baseline security -- don't run raw MCP servers on host networks
6. Rotate credentials now -- if your MCP config has ever been in a repo, gist, or shared machine, assume compromised

Conclusion

The Model Context Protocol unlocks powerful AI-assisted workflows, but its rapid adoption has outpaced security tooling. The scanning campaigns observed in July 2026 are just the beginning -- as MCP becomes the universal plugin interface for AI, it will attract the same attention as npm, PyPI, and Docker Hub.

Developers must treat MCP servers as untrusted third-party code executing with their privileges. Apply the same rigor you would to a production microservice: authenticate, isolate, audit, and monitor. The convenience of npx -y @random/mcp-server comes with a steep hidden cost.

---

Sources:

• Invariant Labs: "MCP Security Notification: Tool Poisoning Attacks" (April 2026)
• Invariant Labs: "WhatsApp MCP Exploited: Exfiltrating Message History via MCP" (April 2026)
• Simon Willison: "Model Context Protocol has prompt injection security problems" (April 2025)
• arXiv:2503.23278 "Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions" (Oct 2025)
• Docker Blog: "Securing Model Context Protocol: Safer Agentic AI with Containers" (May 2025)
• MCPSafe.org security scanner and registry
• arXiv:2504.03767 "MCP Safety Audit: LLMs with the Model Context Protocol Allow Major Security Exploits"
• CyberPress: "Hackers Scan for Exposed MCP Servers, AI Assistant Credentials, and Unauthenticated LLM Endpoints" (July 13, 2026)
• HN discussions: "We scanned 306 MCP servers -- 10% have critical vulnerabilities" (Feb 2026)