30 MCP CVEs in 60 Days. Most Fixes Are Solving the Wrong Problem.

Between January and February 2026, security researchers filed over 30 CVEs against MCP servers, clients, and infrastructure. Path traversals. Command injections. A CVSS 9.6 remote code execution flaw in a package downloaded nearly half a million times.

The response has been predictable: patch the server, publish an advisory, move on.

That response is solving the wrong problem.

The structural gap

Every CVE targets a specific server. Fix one, another appears. The WhatsApp MCP server gets tool poisoning patched. The mcp-remote package gets its command injection fixed. Anthropic’s own MCP Inspector gets its RCE closed.

But the underlying architecture hasn’t changed. The agent still has unrestricted access to every tool the server exposes. There are no rate limits. No spend caps. No argument validation. No read-only modes.

Patching a vulnerability in one server doesn’t prevent the next agent from calling drop_table 200 times on a different server that hasn’t been patched yet.

The vulnerability isn’t in the server. It’s in the gap between the agent and the server where no controls exist.

Servers can’t secure themselves

MCP server authors face an impossible task. They expose tools. The tools do what they say they do. A delete_repository tool deletes repositories. That’s not a bug. That’s the tool working correctly.

The security question isn’t whether the tool works. It’s whether this agent, at this moment, should be allowed to call it.

That decision requires context the server doesn’t have:

• How many times has this agent called this tool today?
• Has it exceeded a spend threshold?
• Is this argument value within acceptable bounds?
• Should this tool be visible to this agent at all?

Servers don’t track state across calls. They don’t know about rate limits. They don’t enforce policies. They execute.

The fix is a layer, not a patch

The pattern that actually works is a proxy between the agent and the server that evaluates every tool call against a policy before forwarding it.

version: "1"
default: deny

tools:
  list_issues:
    rules:
      - action: allow
        rate_limit: 30/minute

  create_refund:
    rules:
      - name: "daily cap"
        rate_limit: 10/day
        on_deny: "Daily refund limit reached"

  delete_repository:
    rules:
      - action: deny
        on_deny: "Repository deletion blocked by policy"

This is what Intercept does. One YAML file defines what the agent is allowed to do. The proxy enforces it at the transport layer. The agent never sees the rules. There’s nothing to reason around, inject past, or bypass.

intercept -c policy.yaml -- npx -y @stripe/mcp-server

Every tool call checked. Every decision logged. Every deny explained.

Why this matters now

The 30 CVEs aren’t a failure of MCP server security. They’re evidence that the protocol is being used in production, at scale, without the control infrastructure it needs.

The MCP spec is a transport protocol. It defines how agents talk to servers. It does not define what agents are allowed to do. That’s a separate layer, and it doesn’t exist by default.

Security researchers scanning 518 MCP servers found 41% had no authentication at all. Over 1,000 servers were discovered with zero authorisation. These aren’t edge cases. This is the default state.

Patching individual servers is necessary. It’s not sufficient. The structural fix is a policy layer that works across all servers, enforced before execution, defined as code.

Getting started

Intercept is open source and works with any MCP server.

# See every tool your server exposes
intercept scan -- npx -y @stripe/mcp-server

# Enforce a policy on every tool call
intercept -c policy.yaml -- npx -y @stripe/mcp-server

Pre-built policies for 130+ MCP servers: policylayer.com/policies

---

Intercept is the open-source control layer for AI agents.

• GitHub
• Policy templates
• Documentation