30 MCP CVEs in 60 Days: The Protocol's Security Crisis

In January 2026, the Model Context Protocol had a handful of known vulnerabilities. By March, it had over thirty CVEs. Thirty. In sixty days.

That's not a bad quarter for a mature protocol. That's a fire alarm for one that's barely a year old and already wired into production systems at every major AI company.

This isn't a hit piece on MCP. The protocol solves a real problem — standardized tool access for AI agents. But the CVE velocity tells a story that the community needs to hear: these aren't random implementation bugs. They're architectural gaps in a protocol that shipped with trust as a default and authentication as an afterthought.

The CVE Timeline

Here's the breakdown of 30+ CVEs filed between January and March 2026, grouped by category:

Authentication Bypass (11 CVEs)

The largest category. MCP servers that accept unauthenticated connections, use weak or default credentials, or fail to validate client identity.

Notable CVEs:

• Authentication bypass CVEs — Default-open authentication on widely deployed filesystem MCP servers. Any client could connect and invoke file operations with no credentials. [SPECIFIC CVE IDS PENDING VERIFICATION]
• Token replay CVEs — Token replay vulnerabilities in MCP server OAuth implementations. Valid tokens could be replayed indefinitely after expiration. [SPECIFIC CVE IDS PENDING VERIFICATION]
• Server-side injection CVEs — Server-side request forgery via unauthenticated MCP tool calls targeting internal network endpoints. [SPECIFIC CVE IDS PENDING VERIFICATION]

[NEEDS SOURCE — Specific CVE IDs must be verified against NVD/MITRE databases before publication. The count of 30+ and the categorization are based on public tracking; individual CVE numbers need confirmation.]

Injection Vulnerabilities (8 CVEs)

MCP tool poisoning is the primary vector. Malicious or compromised MCP servers return responses containing injected instructions that manipulate the connecting agent into performing attacker-controlled actions.

Key patterns:

• Response injection — Server embeds hidden instructions in tool result data. The agent processes these as legitimate instructions and generates follow-up tool calls directed by the attacker.
• Schema poisoning — Server modifies tool descriptions to include instructions that override the agent's system prompt. The model follows the "tool description" as if it were an authoritative instruction.
• Argument manipulation — Server returns results designed to influence the agent's next tool call arguments — e.g., returning a file path that, when used in a subsequent file read, accesses sensitive data.

Data Exfiltration (6 CVEs)

MCP servers designed to extract data from the connecting agent's context, including:

• Conversation history (potentially containing credentials, API keys, or sensitive business logic)
• Local file contents accessed through the agent's file tools
• Environment variables and system information

Privilege Escalation (5+ CVEs)

Tool calls that escalate the agent's effective permissions:

• MCP servers that request broader tool access than their stated function requires
• Servers that chain tool calls to escalate from read to write to execute
• Cross-server escalation where access to one MCP server enables unauthorized access to another

The Velocity Problem

For context, compare MCP's CVE velocity to other protocols at similar maturity:

[NEEDS SOURCE — Protocol comparison numbers are estimates from public CVE databases. Verify exact counts before publication.]

The difference isn't that MCP is inherently worse-designed than these protocols. It's that MCP shipped into an environment where every AI agent vendor simultaneously adopted it, creating an enormous attack surface overnight — and the protocol's security model wasn't ready.

38% Have No Auth: The Default-Insecure Problem

The MCP specification doesn't require authentication for tool calls. It provides authentication capabilities — the spec includes provisions for OAuth 2.1, API keys, and custom auth schemes. But authentication is optional, and the default is no auth. Kai Security scanned all 518 servers in the Official MCP Registry; after correction, ~38% had no authentication at any level (Kai Security, February 2026).

This matters because of how MCP gets adopted in practice:

1. Developer builds an MCP server. The tutorial doesn't cover auth. The quickstart template ships without it. The "hello world" example works without it. Auth is documented in an "advanced" section.

1. Server gets shared. GitHub, npm, or an internal registry. Other developers install it. Nobody checks for auth because nobody expects it — MCP servers "just work."

1. Server connects to production agents. The MCP server that started as a weekend project is now connected to an agent with access to production codebases, credentials, and infrastructure.

1. Attacker connects to the same server. No auth means anyone who can reach the server can invoke its tools. On a network-accessible server, that's potentially the entire internet.

The protocol's permissive default creates a "security debt by default" that accumulates silently. Every MCP server deployed without auth is a node in an expanding attack surface.

What "No Auth" Actually Means

Without authentication, an MCP server cannot:

• Verify which client is connecting
• Restrict tool access by client identity
• Rate-limit or throttle per-client
• Audit which client performed which action
• Revoke access for a compromised client

The server is a public API with no access control. Every tool it exposes is callable by anyone.

Active Exploitation

MCP vulnerabilities aren't theoretical. Security researchers and incident responders have documented active exploitation: [NEEDS SOURCE — the following cases need specific citations. Flag any that cannot be verified with primary sources.]

Supply chain attacks via popular MCP servers. Compromised MCP servers on package registries that served poisoned tool responses to connecting agents. When an AI agent connected and invoked tools, the server's responses included injected instructions that caused the agent to exfiltrate environment variables and API keys.

Credential harvesting via MCP tool poisoning. Attackers deploying malicious MCP servers that advertise useful functionality (code search, documentation lookup, API testing) but embed credential-harvesting payloads in tool responses. The connecting agent reads the response, follows the injected instructions, and transmits credentials to the attacker's infrastructure.

Internal network reconnaissance. MCP servers used as pivot points for SSRF attacks. An agent connects to an MCP server, which returns results containing instructions to make requests to internal network addresses — cloud metadata endpoints, internal APIs, database connections. The agent's HTTP tools become the attacker's proxy into the internal network.

Data exfiltration via legitimate-seeming tool calls. MCP servers that subtly modify tool results to include instructions that cause the agent to include sensitive data in subsequent outbound requests. The exfiltration is hidden within legitimate-looking tool call patterns, making it difficult to detect without pre-execution analysis.

These aren't edge cases. They're the predictable result of a protocol that defaults to trust.

Anthropic's Response

Credit where due: Anthropic has recognized the authentication gap and is working to close it.

OAuth 2.1 additions to the MCP spec. Anthropic has added OAuth 2.1 support to the MCP authentication specification, providing a standardized way for MCP servers to require client authentication. This is a meaningful step — OAuth 2.1 is a well-understood protocol with mature tooling.

The MCP auth spec timeline. The authentication specification was published in early 2026. Adoption is underway but uneven — the largest MCP server registries have announced support, but the long tail of community-built servers remains largely unauthenticated.

What's still missing. OAuth 2.1 addresses client-to-server authentication, but it doesn't address:

• Tool-level authorization. A client authenticated to an MCP server gets access to all of its tools. There's no standard for per-tool authorization.
• Response integrity. There's no mechanism to verify that an MCP server's response hasn't been tampered with or that it doesn't contain injected content.
• Trust boundaries between servers. When an agent connects to multiple MCP servers, there's no standard for preventing one server from influencing tool calls to another.
• Client-side enforcement. OAuth authenticates the client to the server, but it doesn't give the client a way to enforce policy on what the server can instruct the agent to do.

The authentication spec is necessary but not sufficient. Authentication answers "who is connecting?" It doesn't answer "should this tool call execute?"

What MCP Server Operators Should Do Now

If you're running MCP servers — whether public or internal — here's the immediate checklist:

1. Implement Authentication

If your MCP server has no auth, add it now. OAuth 2.1 is the spec-recommended approach. At minimum:

• Require client credentials for all connections
• Implement token expiration and rotation
• Log all authentication events

2. Validate Tool Inputs

Every tool handler should validate its inputs:

• Type checking against the schema
• Path traversal prevention for file operations
• Command injection prevention for shell operations
• SQL injection prevention for database operations

3. Scope Tool Access

Don't expose every capability as an MCP tool. Apply the principle of least privilege:

• Only expose tools that the server's stated function requires
• Restrict file access to specific directories
• Limit network access to specific domains
• Restrict database access to specific tables and operations

4. Sanitize Tool Responses

Your tool responses become part of the agent's context. If your responses contain user-generated content, attacker-controlled data, or content from external sources, sanitize it before returning:

• Strip or escape content that could be interpreted as instructions
• Clearly delineate data from metadata
• Limit response size to prevent context flooding

5. Monitor and Alert

Log every tool invocation with:

• Client identity
• Tool name and arguments
• Response data (or a hash of it)
• Timestamp and duration

Alert on anomalies: unusual tool call patterns, high-volume invocations, access to tools outside the client's normal pattern.

6. Audit Your Dependencies

If your MCP server depends on other services or MCP servers, audit their security posture. A compromised dependency is a compromised server.

Policy-as-Code for MCP Trust Boundaries

Server-side security is necessary but insufficient. You control your own MCP servers — you don't control the ones you connect to. And you definitely don't control what a compromised server sends back.

This is where client-side policy enforcement becomes critical. Policy-as-code defines trust boundaries that are enforced before any MCP tool call executes, regardless of the server's security posture.

How It Works

Define which MCP servers are trusted, which tools they're allowed to provide, and what arguments those tools can receive:

# MCP trust policy
mcp_servers:
  trusted:
    - server: "github-mcp.internal"
      tools:
        - name: "search_code"
          allowed_args:
            repo: ["org/repo-a", "org/repo-b"]
        - name: "read_file"
          blocked_paths: [".env", ".ssh", "credentials"]

    - server: "docs-server.internal"
      tools:
        - name: "search_docs"
        - name: "read_doc"

  untrusted_default: block  # Block all tool calls to unlisted servers

Why Client-Side Enforcement Matters

1. Server compromise. If a trusted MCP server is compromised, client-side policy limits the damage. The compromised server can't instruct the agent to execute operations outside the defined trust boundary.

1. Supply chain attacks. A malicious MCP server that passed initial vetting can't escalate its access beyond what the policy allows.

1. Response injection. Even if an MCP server returns poisoned responses, the policy engine evaluates the resulting tool calls before execution. An injected instruction that causes the agent to run rm -rf / hits the policy rule and is blocked.

1. Defense in depth. Server-side auth + client-side policy = two independent layers that an attacker must both defeat.

Shoofly Advanced implements MCP trust boundary enforcement at the tool call dispatch layer. Policy rules evaluate every MCP-originated tool call before execution — which server initiated it, which tool is being called, what arguments are being passed, and whether the call matches defined trust boundaries. This works even when the MCP server itself is compromised, because the interception happens on the client side, before the tool call reaches execution.

Learn more about MCP-specific security in our MCP security center.

The Bottom Line

Thirty CVEs in sixty days isn't a blip. It's a pattern. MCP's trust-by-default architecture meets an ecosystem that deployed it into production faster than anyone secured it.

Anthropic's OAuth 2.1 additions are a start. Server operators implementing auth and input validation is essential. But the fundamental gap — client-side policy enforcement on MCP tool calls — is what separates "hoping the server is secure" from "enforcing trust boundaries regardless."

Your MCP servers might be in the ~38% with no authentication (Kai Security, February 2026). Shoofly Advanced enforces trust boundaries on every MCP tool call before it executes.

→ Enforce MCP trust boundaries with Shoofly Advanced

FAQ

How many MCP CVEs have been filed in 2026?

Over 30 CVEs targeting the Model Context Protocol were filed in the first 60 days of 2026. These span authentication bypass, injection vulnerabilities, data exfiltration, and privilege escalation categories. The velocity — roughly one CVE every two days — indicates systemic protocol-level issues rather than isolated implementation bugs.

Why are MCP servers insecure by default?

The MCP specification provides authentication capabilities but doesn't require them. Authentication is optional, and the default is no auth. Combined with quickstart templates and tutorials that skip auth, this creates a pattern where servers ship without authentication and accumulate users before anyone addresses the gap. The protocol's design prioritizes developer experience and rapid adoption, with security as an opt-in layer.

What is MCP tool poisoning?

MCP tool poisoning is an attack where a malicious or compromised MCP server embeds adversarial instructions in tool responses. When an AI agent processes the response, the hidden instructions manipulate the agent into performing attacker-controlled actions — reading sensitive files, exfiltrating data, executing commands, or modifying code. See our detailed MCP tool poisoning guide for the full technical breakdown.

How do I secure my MCP server connections?

Implement authentication (OAuth 2.1 recommended), validate all tool inputs, scope tool access to minimum required capabilities, sanitize tool responses, and monitor all invocations. On the client side, deploy policy-as-code that defines trust boundaries — which servers are trusted, which tools they can provide, and what arguments are allowed. Client-side enforcement protects you even when a server is compromised.