Unauthenticated MCP servers leak data and permissions
Researchers found Internet-exposed Model Context Protocol (MCP) servers that let anyone list and invoke agent tools. Many return real data, some proxy privileged backends, and a subset yield cloud credentials via metadata access. Tool catalogues often include write and delete operations. Most use legacy protocol versions without authentication.
Model Context Protocol (MCP) is meant to let agents call tools cleanly. Too many teams have put those servers on the open Internet with no authentication. The protocol handshakes, advertises its tool list, and invites you in. That self-description is the win for attackers: reconnaissance becomes one request.
How the exploit chain unfolds
You connect. Roughly seven in ten exposed servers hand you a machine-readable tool catalogue with parameters and descriptions. From there, you invoke. In about 42 percent of cases, the server replies with real data. I’m talking employee PII, internal business records, issue-tracker content, full application-security findings, even retirement-account balances. Some deployments front Business Intelligence (BI) and databases, exposing schema inspection alongside a query_sql tool. That’s a neat two-step: list tables, then run arbitrary reads against production.
Others are worse: the MCP server is a privileged proxy or wraps a Large Language Model (LLM) agent that can hit the network or shell out. A simple prompt can coerce those agents into fetching “helpful” URLs. On a confirmed subset, that behaviour reached cloud instance metadata and came back with temporary credentials. That is classic SSRF energy routed through an AI tool. With creds in hand, you pivot inside the cloud account.
Plenty of catalogues also advertise write and delete. Identity and Access Management (IAM) operations, CRM mutations, the sort of verbs you never want unauthenticated. The researchers didn’t execute destructive calls, so we don’t know the success rate in the wild. But if the server happily returns real reads, it’s reasonable to assume some writes land too.
Why MCP makes this easy
A single generic client works across vendors because the protocol is common and self-describing. That shrinks attacker effort and scales scanning. Nearly all observed servers still negotiate the original 2024-11-05 version, which predates the March 2025 additions for OAuth 2.1 and tool flags like readOnlyHint and destructiveHint. So your client can enumerate and call tools, and the server won’t signal risk levels or enforce proper auth.
Two more nasty footnotes. First, malicious calls look just like normal agent usage; without prompt and invocation logging, attribution is smoke. Second, exposed servers sometimes front multiple backends. That turns a single unauthenticated MCP into a supply-chain style multiplier: data exfil, cloud credential theft, and lateral movement across whatever those tools touch. The exact blast radius varies, but the path in is boringly consistent.
