The risk hiding behind exposed MCP servers

What it is

Wiz Research's field study of internet-exposed Model Context Protocol servers, quantifying how common they are and demonstrating the impact classes. The summary gives the headline (1 in 6 environments); the page adds the funnel metrics, the March 2025 spec boundary, and — most usefully for an engineer — why these are hard to detect and where the one detection opportunity actually lives.

The numbers the summary omits

• MCP is present in ~80% of cloud environments.
• Of exposed servers: ~70% return their full tool catalog to an anonymous caller; ~42% return real data when a tool is called; ~10% expose a sensitive backend. SSRF-to-metadata (yielding temporary credentials) is a "small but confirmed" share.

The version boundary that matters

Authentication (OAuth 2.1) was added to the MCP spec in March 2025. That same revision added tool annotations — readOnlyHint and destructiveHint — that let a client distinguish safe reads from dangerous writes. Nearly all servers found still negotiate 2024-11-05, which predates both, so clients cannot even tell reads from destructive writes from the catalog alone.

Why it evades detection

A malicious call is near-indistinguishable from a legitimate one: the server makes the same backend request with the same embedded credential it always uses, and the backend answers a well-formed, authorized request. No failed login, no denied-access spike, no alert. The fix is therefore preventive, not detective.

The one exception is the code-execution / agent-wrapper class: the agent's prompt and invocation logs may show a suspicious request (a prompt asking for secrets, a command to run) even when network telemetry is clean — but only if the deployment captures those prompts, and many don't.

What to do

• Audit which MCP servers are internet-reachable and whether they require auth.
• If a server must be public, gate tool execution behind auth even when the catalog is open — use the spec's built-in OAuth 2.1. Otherwise scope the server's permissions to block anonymous sensitive/destructive access.
• Enable agent prompt and invocation logging — for the code-execution class it's the only trace an attack leaves.
• Treat the server like a privileged service account: least privilege, backend credentials scoped to the bare minimum.

Concrete leak examples (mechanism)

Direct secret exposure needs no agent or pivot: cloudwatch_get_lambda_logs returned Lambda env vars containing API keys; another tool's response embedded a DB connection string with credentials. A BI server paired query_sql with get_connection_schemas/get_connection_table_columns, letting an anonymous caller enumerate every connected database and run arbitrary queries.