The Model Context Protocol has a security problem that goes far beyond individual CVEs. BlueRock Security scanned over 7,000 MCP servers and found 36.7% are potentially vulnerable to server-side request forgery (SSRF). Separately, Trend Micro discovered 492 MCP servers exposed to the public internet with zero authentication.

These aren’t isolated bugs. They’re structural failures in how the MCP ecosystem deploys, configures, and secures its infrastructure.

The BlueRock Findings

BlueRock’s research focused on SSRF vulnerabilities — attacks where a server can be tricked into making requests to internal resources it shouldn’t access.

In a proof-of-concept against Microsoft’s MarkItDown MCP server, researchers exploited SSRF to reach the AWS EC2 instance metadata endpoint and retrieve IAM access keys, secret keys, and session tokens. A misconfigured MCP server became a direct gateway to the victim’s cloud infrastructure.

The attack path:

  1. Attacker sends a crafted request to an MCP server
  2. The server follows the request to an internal endpoint (e.g., 169.254.169.254)
  3. Cloud credentials are returned to the attacker
  4. Attacker now has access to the victim’s AWS/GCP/Azure environment

Over one-third of scanned servers were potentially vulnerable to this class of attack.

492 Servers With No Auth

Trend Micro’s separate scan found 492 MCP servers accessible from the public internet with no authentication and no encryption. Many had admin or debug endpoints exposed.

These aren’t sophisticated attack targets. They’re open doors. Anyone who finds them can connect, issue tool calls, and potentially access whatever resources the MCP server has permissions to reach — databases, file systems, APIs, cloud services.

Simon Willison’s “Lethal Trifecta”

Security researcher Simon Willison has articulated a framework that explains why these vulnerabilities matter so much in agent contexts. He calls it the “lethal trifecta” — three properties that, when combined in a single system, make prompt injection a system-level threat:

  1. Access to private data — the agent reads files, databases, API keys, emails
  2. Exposure to untrusted content — the agent processes user inputs, web pages, documents, third-party tool outputs
  3. Ability to communicate externally — the agent can send HTTP requests, messages, write to remote endpoints

Most agent frameworks, including OpenClaw with MCP tools, combine all three by design. An attacker hides instructions in content the agent reads (a webpage, email, document). The model treats them as commands. It uses its data-access tools to retrieve secrets. Then it uses its outbound capabilities to exfiltrate them.

The SSRF vulnerabilities in MCP servers are particularly dangerous because they give attackers a way to skip the prompt injection step entirely — they can directly abuse the server’s network position without needing to manipulate the LLM at all.

The Broader Picture

This is the third major MCP security story we’ve covered in recent weeks:

  • Claude Code MCP CVEs (CVE-2025-59536, CVE-2026-21852) — supply chain attacks via malicious .mcp.json files in cloned repos
  • MCP Atlassian RCE (CVE-2026-27825/27826) — unauthenticated remote code execution and SSRF through path traversal
  • Now: systemic SSRF exposure — 36.7% of servers vulnerable, 492 with zero auth

Each incident reveals a different layer of the same problem. Individual tool vulnerabilities. Supply chain poisoning. And now, infrastructure-wide misconfiguration.

The MCP ecosystem grew fast. Security didn’t keep up.

What This Means for OpenClaw Users

OpenClaw’s architecture is model-agnostic and tool-agnostic. That flexibility is a strength — but it means you inherit whatever security posture your MCP servers have.

Practical steps:

Audit your MCP servers. Check every MCP server you’ve configured. Are any bound to 0.0.0.0 instead of 127.0.0.1? Do they require authentication?

Network isolation. MCP servers should not have unrestricted outbound access. Block access to cloud metadata endpoints (169.254.169.254) at the firewall level. Use network segmentation to limit what internal resources they can reach.

Minimize tool permissions. Each MCP server should have the minimum permissions needed for its function. A Confluence integration doesn’t need access to your AWS credentials.

Update aggressively. MCP servers are young software with active vulnerability discovery. Treat them like any internet-facing service — patch quickly.

Consider the trifecta. If your agent has access to private data, processes untrusted inputs, and can communicate externally, you have a high-risk configuration. Add approval gates (ClawBands) or restrict outbound capabilities.

The Uncomfortable Truth

The MCP ecosystem is building powerful tools for AI agents without the security infrastructure those tools demand. Individual developers ship MCP servers that handle sensitive operations — file access, database queries, cloud API calls — with the same casual defaults you’d use for a local dev tool.

But these aren’t local dev tools anymore. They’re components in autonomous systems that process untrusted inputs and take real actions. The security bar needs to match the capability level.

One-third of servers vulnerable to SSRF. Hundreds with zero authentication. The numbers tell a clear story: the MCP ecosystem needs to treat security as a prerequisite, not an afterthought.

OpenClaw’s security configuration guide covers hardening your agent’s tool access, network exposure, and approval workflows.