MCP Security in Production: 8 Attack Classes and Required Mitigations

The Eight Attack Classes

MCP's security best-practices document, published and maintained alongside the spec, names these as required (MUST-level) mitigations, not optional hardening:

• Confused deputy — via OAuth proxy servers with static client IDs and consent cookies. Mitigated by mandatory per-client consent stored and checked before forwarding to a third-party authorization server.
• Token passthrough — MCP servers MUST NOT accept tokens not explicitly issued for them; forwarding an un-validated upstream token to a downstream API breaks audience validation and audit trails.
• SSRF during OAuth metadata discovery — a malicious server can point a client at cloud metadata endpoints or internal IPs via authorization server URLs. Mitigated by enforced HTTPS, private-IP-range blocking per RFC 9728 §7.7, and redirect validation.
• State handle hijacking — see below. Mitigated by non-deterministic handles bound server-side to authenticated identity, never treated as authentication by themselves.
• Local server compromise — a locally-spawned MCP server (stdio) runs with the client's OS privileges. Mitigated by mandatory pre-connection consent dialogs showing the exact command, plus sandboxing.
• OAuth authorization URL injection — malicious URL schemes leading to XSS or, via shell-based URL opening, RCE. Mitigated by strict scheme allowlisting and never shelling out to open a URL.
• Mix-up attacks — across multiple authorization servers, since PKCE alone doesn't prevent them. Mitigated by binding the OAuth response to the recorded authorization server per RFC 9207.
• Scope over-grant — publishing and requesting broad omnibus scopes. Mitigated by a progressive least-privilege model: minimal baseline scope, incremental step-up via challenge.

The specific mitigations above — per-client consent storage, audience validation, IP-range blocking, non-deterministic server-bound handles — are what the protocol's own security documentation treats as the bar. Generic OAuth support doesn't clear it.

The New Attack Surface: Statelessness

MCP's 2026-07-28 spec revision removed the initialize handshake and the Mcp-Session-Id header entirely. Any server that needs cross-call state — a shopping cart, a workflow ID — now must mint an explicit handle passed back as an ordinary tool argument on every subsequent call. This directly created a new named failure mode: a server can no longer assume "the client that called X is the same client calling Y" from connection identity alone. If a server doesn't bind handles to authenticated identity server-side, an attacker who obtains or guesses a handle can access another user's state.

Handle strings passed inside a model's own conversation aren't visible at the HTTP layer, which makes this class of attack difficult for traditional network gateways to detect — it doesn't look like a session-hijacking attempt from the wire. The NSA's May 2026 guidance named the underlying design gap directly: associating a session to an identity is not defined by the MCP protocol itself. That is now the server implementer's explicit responsibility, not something the protocol guarantees for you.

Documented Incidents

These aren't theoretical. In January 2026, researchers identified over 42,000 exposed instances of a popular agent-hosting framework in a single internet scan, with more than 1,000 running unauthenticated MCP endpoints. Separately, a documented supply-chain compromise shipped a trojanized MCP server via a months-long fake-developer-persona campaign, exfiltrating credentials and session tokens on install. A third disclosed incident found an IDE that didn't re-validate an approved MCP server configuration after later modification — a one-time approval that silently allowed remote code execution on every subsequent launch once the payload was swapped. Each of these traces to implementation choices by specific hosts and servers, not a flaw in the MCP spec itself — which is exactly why evaluating any third-party MCP server as a supply-chain dependency, not as pre-vetted because it's registry-listed, matters.

What "We Support OAuth" Actually Needs to Mean

The 2026-07-28 authorization spec explicitly builds in two OAuth security RFCs, not an MCP-specific ad hoc scheme: RFC 9207 (iss parameter validation, mitigating mix-up attacks across multiple authorization servers) and RFC 9728 (protected resource metadata, informing SSRF mitigations during discovery). "We use OAuth" is weak. "We validate iss per RFC 9207 and block private IP ranges per RFC 9728 §7.7 during metadata discovery" is what the spec itself asks for.

For the broader protocol context these mitigations sit inside — transport choice, discovery, and the rest of the 2026-07-28 redesign — see MCP and A2A in Production. The term for the specific attack surface introduced by the statelessness redesign is defined in the glossary as State Handle Hijacking.