MCP opens trust all the way by default.
Tightening it is left to you.

A widely shared post claims a "CVE-2026-32814 / X-MCP-Authenticated header auth bypass." Before anything else: it is fictional.

MCP has two transports. stdio runs over a local socket with no authentication mechanism; it assumes both ends are trusted processes on the same machine — fine in local dev, broken the moment you go hosted or multi-tenant. HTTP gained formal OAuth 2.1 (with PKCE) support in June 2025, but the spec says HTTP servers can implement authorization, not that they must. Authorization is explicitly optional, and most public servers don't implement it.

On first connection, the client fetches the server's tool manifest — names, descriptions, parameter schemas. The user reviews it, approves, and the agent starts calling. What most teams don't know: those definitions are fetched dynamically at session start, and the protocol includes notifications/tools/list_changed, which lets a server push updated schemas mid-session without any client re-approval. The spec requires neither immutable definitions nor content hashing. An approved server can serve a different manifest on every connection.

A peer-reviewed study (arXiv:2603.22489, March 2026) evaluated seven major MCP clients against changed or malicious tool definitions; five of the seven implemented no static validation, accepting whatever the server returned. Even clients with approval dialogs are often vulnerable, because the malicious instructions appear below the visible area and rely on users clicking Approve without scrolling.

Prompt injection usually needs access to the system prompt or user input. MCP opens another path: tool output. When a tool returns data, the model receives it as trusted context — the result of something it asked for. If that data contains text structured to look like an instruction, the model will often follow it. More capable models are, on average, more vulnerable, because they follow instructions more precisely.

The attack scales with your tool surface. Every data source the agent reads through MCP — databases, issue trackers, inboxes, document stores — is a potential injection point. FlowVerify's control lives at the data layer: strict output schemas defining exactly what fields each tool can return, validated before the model sees them, with any free-form text treated as inert data rather than instruction candidates.

This failure mode is structural. MCP grants the agent the full tool set at session start, and all those credentials remain present for the entire session. This is ambient authority: the agent holds everything simultaneously, not just what the current task needs. A server exposing twenty tools receives one OAuth session token covering all of them; after the initial handshake, there is no per-tool authorization barrier.

Ambient authority enables the confused deputy attack. Tool A has read access to a low-privilege store and returns output structured as an instruction for Tool B, which has write access to something sensitive. The model reads Tool A's output as trusted context and invokes Tool B accordingly. Neither tool was compromised; no auth check failed. The attack succeeds because both credentials were present at once and the model can't distinguish tool-output-as-data from tool-output-as-instruction.

With the fictional CVE set aside, the real, verifiable vulnerabilities make the point better. They converge on the same repeated mistake: the official SDKs' localhost HTTP transports don't validate the request's Host / Origin header by default, so they get hit by DNS rebinding or cross-site requests — categorised as Insecure Default Initialization (CWE-1188).

How DNS rebinding works here

Because MCP servers commonly expose tools that read source, run shell, or speak to cloud APIs, a rebound request can drive the whole tool surface from any browser tab the user happens to leave open. MCPSafe notes that a bearer token alone doesn't help: if the token is in a previously-set cookie or header, the rebinding request carries it; the only reliable defense is a per-request Host check.

All of the following are verifiable on NVD or official GitHub Security Advisories, each with a patch version:

Lining up the same class of flaw across the TypeScript and Go SDKs, the conclusion matches FlowVerify and the NSA: this isn't one implementer's slip, but the protocol's early "make it convenient first" default replicated into every official implementation — each later closed by adding Host/Origin validation.

On May 20, 2026, the NSA published "Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation." Its overall judgment: MCP's rapid adoption has outpaced the development of appropriate security safeguards, leaving organizations exposed to risks the protocol's designers and implementers did not fully anticipate. On the left are the eight risks it names; on the right, the nine matching recommendations.

FlowVerify maps each failure mode to its enabling condition, a documented example, and the primary mitigation.

Beyond the per-row mitigations, FlowVerify lists practices that should be defaults for every production deployment:

• Audit at the transport layer. Log every tool invocation — name, parameters, output hash. A compromised agent won't announce itself; anomalous tool-call sequences are the primary signal, so build this before something goes wrong.
• Enforce TLS and OAuth 2.1 on every HTTP MCP endpoint. The spec supports it as of June 2025; there is no production argument for an unauthenticated HTTP MCP server.
• Load tools per task, not per session. Several agent frameworks support per-turn tool registration. Narrowing the credential surface is the highest-impact architectural change you can make.
• Validate output schemas before the model sees them. Define what each tool can return and reject anything outside it; free-form external text should never be interpolated into a system prompt or passed as a parameter to another tool.
• Pin tool manifests with mcp-scan or your own hash. mcp-scan (open-source, Invariant Labs) scans Claude, Cursor, and Windsurf configs and flags manifest changes between sessions.

FlowVerify notes the MCP spec working group is discussing tool-definition immutability, finer-grained permission scoping, and mandatory auth for HTTP transports, so several of these gaps are likely to narrow in the 2026 spec revisions. The controls above address what's exploited today.