MCP Servers Are the New Attack Surface

The Model Context Protocol has a security database now. It has 50 entries.¹

Thirty CVEs were filed in 60 days. Among 2,614 MCP implementations surveyed, 82% had file operation vulnerabilities prone to path traversal. Between 38% and 41% of servers lacked authentication entirely.² The official MCP Inspector tool — the thing developers use to debug MCP servers — had an RCE vulnerability. The widely-used mcp-remote package had an OS command injection bug.¹

This is not a theoretical attack surface. These are real CVEs in real packages that real developers are connecting to Claude Code, Codex CLI, and Cursor right now.

TL;DR

MCP servers are the fastest-growing integration surface in the agent ecosystem. They are also the least audited. The vulnerability database has 50 entries: 13 Critical, 32 High. Input validation failures and prompt injection account for 30 of the 50. Three SSRF vulnerabilities in three different MCP servers surfaced in a single day this week.³ The pattern is clear: the community is shipping MCP servers faster than it is reviewing them.

Key Takeaways

• Claude Code users: Every MCP server you connect is a trust boundary you are extending. Run claude mcp list right now and audit what you have connected. If you are running community MCP servers you installed months ago, check whether they have been patched since.
• Harness builders: Your PreToolUse hooks are your last line of defense before an MCP tool call reaches an unaudited server. Consider hooks that validate MCP tool inputs before execution — especially for servers that accept URLs, file paths, or shell commands.
• MCP server authors: The MCP spec says there “SHOULD always be a human in the loop.” Treat that as MUST. Validate all inputs. Never pass user-controlled strings to shell commands via string interpolation. Never trust $ref values in OpenAPI specs without URL validation.

The Numbers

The Vulnerable MCP Project maintains a database of documented MCP security issues.¹ The current state:

Severity: 13 Critical, 32 High, 5 Medium.¹ Thirty-two security researchers contributed findings. The affected servers include Anthropic’s own Git MCP server, the official MCP Inspector, Microsoft MarkItDown, GitHub Kanban, Figma, Jira, Grafana, Neo4j, Kubernetes, and 20+ community-built servers.¹

The survey finding is the most damning: 82% of 2,614 MCP implementations had file operation vulnerabilities prone to path traversal.² Four out of five MCP servers will let an attacker read files they should not have access to.

Five Attack Patterns

The 60-day CVE wave revealed five recurring patterns:²

1. Tool poisoning. Malicious instructions embedded in MCP tool descriptions. The agent reads the description, trusts it, and follows the hidden instructions using its own authorized tools. The poisoned tool never executes — the agent’s legitimate tools carry out the attack. We covered this pattern in the deploy-and-defend paradox: the trust is transitive, the audit is not.

2. Prompt injection via external data. MCP servers that fetch content from GitHub issues, Slack messages, emails, or web pages bring attacker-controlled text into the agent’s context. The injection does not target the MCP server — it targets the agent reading the server’s output. The silent egress attack surface is the general case; MCP servers are the most common vector.

3. Trust bypass after initial approval. Claude Code asks you to approve an MCP server the first time. After that, tool definitions can change between sessions without re-prompting in all cases — a server that was safe at install time can behave differently at update time. The re-validation gap is structural: the protocol does not require cryptographic signing of tool descriptions.²

4. Supply chain compromise. Backdoored MCP servers published to registries, including packages that impersonate legitimate servers. The same supply chain pattern we documented in the supply chain is the attack surface, applied to the MCP ecosystem.

5. Cross-tenant exposure. Shared hosting environments where multiple MCP servers can intercept each other’s function calls before execution.⁴ Isolation boundaries that look solid from the outside break down when multiple servers share a process or container.

The SSRF Pattern

Three SSRF vulnerabilities in three different MCP servers surfaced in a single scan this week:³

• n8n-mcp: Authenticated SSRF via instance host injection
• mcp-from-openapi: SSRF via $ref values in OpenAPI specifications — a malicious spec with internal URLs causes the server to fetch those resources during initialization
• stata-mcp: Insufficient validation of user-provided URLs

SSRF in MCP servers is particularly dangerous because the server typically has network access that the agent does not. Here is how a single malicious OpenAPI spec becomes credential theft:

Step 1. An attacker publishes a legitimate-looking MCP server that wraps an external API. The server uses mcp-from-openapi to generate tools from an OpenAPI specification.

Step 2. The OpenAPI spec contains a $ref pointing to an internal address:

components:
  schemas:
    Config:
      $ref: "http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name"

Step 3. During initialize(), the MCP server resolves the $ref by fetching the URL. The server runs on your infrastructure — inside your VPC, on your laptop, in your CI container. The request goes to the AWS metadata endpoint from a trusted source.

Step 4. The metadata endpoint returns temporary IAM credentials: access key, secret key, session token.

Step 5. The server now has your cloud credentials. It can exfiltrate them in tool responses, log them to an external endpoint, or use them directly.

The agent never did anything malicious. The user approved the MCP server. The OpenAPI spec looked normal. The $ref resolution happened at the library level, below where anyone reviews. The SSRF converted the MCP server’s network position into the attacker’s network position.

Microsoft patched a critical Azure MCP SSRF (CVE-2026-26118) in March 2026 — the same pattern applied to Azure: a high-severity elevation-of-privilege vulnerability that could steal authentication tokens and grant unauthorized access to Azure resources.⁵

What To Do

Audit your connected servers. Run claude mcp list and review every server. Check each against the Vulnerable MCP Project database.¹ Remove servers you are not actively using.

Pin server versions. If you install MCP servers from npm or pip, pin the version. Do not auto-update. Review changelogs before upgrading — the trust bypass pattern means an update can change tool definitions without re-approval.

Add input validation hooks. A PreToolUse hook on MCP tool calls can validate inputs before they reach the server:

#!/bin/bash
# .claude/hooks/validate-mcp-input.sh
INPUT_JSON=$(cat)
TOOL_NAME=$(echo "$INPUT_JSON" | jq -r '.tool_name // empty')

# Block MCP tools that accept URLs from passing internal addresses
if echo "$TOOL_NAME" | grep -q "^mcp__"; then
  TOOL_INPUT=$(echo "$INPUT_JSON" | jq -r '.tool_input | tostring')
  if echo "$TOOL_INPUT" | grep -qiE '(169\.254\.|10\.|172\.(1[6-9]|2|3[01])\.|192\.168\.|localhost|127\.0\.0\.1|metadata\.google|169\.254\.169\.254)'; then
    echo "Blocked: MCP tool input contains internal/metadata address" >&2
    exit 2
  fi
fi
exit 0

Consider transport isolation. HTTP MCP servers run in their own process with explicit network boundaries. Stdio servers share the agent’s process context. Neither transport is inherently safe — the bigger factor is whether the server has access to credentials, internal networks, or sensitive file paths. Choose the transport that gives you the isolation boundaries your threat model requires.

Watch the database. The Vulnerable MCP Project at vulnerablemcp.info is the closest thing to a CVE tracker for the MCP ecosystem. Check it before installing new servers.

The MCP ecosystem is growing fast — 3,000+ indexed servers and 100 million monthly downloads.⁶ The security posture is not growing with it. Fifty vulnerabilities in a database that did not exist a year ago. The protocol is not the problem. The implementations are.

Sources

Frequently Asked Questions

Are the MCP servers bundled with Claude Code affected?

The vulnerabilities primarily affect community-built and third-party MCP servers, not the core Claude Code MCP infrastructure. However, the official MCP Inspector tool did have an RCE vulnerability, so “official” does not mean “immune.”

Should I stop using MCP servers?

No. MCP is a powerful integration layer. But treat every MCP server as a trust boundary. Audit what you have connected, pin versions, and add input validation hooks for servers that accept URLs, file paths, or shell commands.

How do I check if my MCP servers are vulnerable?

Run claude mcp list to see your connected servers. Cross-reference each against the Vulnerable MCP Project database. Check the server’s GitHub repository for recent security advisories.