12 minute read

“Thirty CVEs in sixty days. The protocol everyone is adopting for AI agents has the security posture of a 2005 PHP application.”

TL;DR

36.7% of public MCP servers carry SSRF vulnerabilities. 41% have no authentication. Thirty CVEs landed in two months with command injection, path traversal, and SSRF repackaged inside AI agent infrastructure. The OWASP MCP Top 10 just dropped. Here is what breaks, why, and how to harden your deployment. For background on how prompt injection exploits tool-calling agents, see Prompt injection defense.

A network cabinet where one cable bypasses the firewall appliance to reach an internal switch

What just happened to MCP security?

Between January and February 2026, security researchers filed over 30 CVEs against MCP servers, clients, and infrastructure. One new vulnerability every two days for a protocol that didn’t exist before November 2024.

The breakdown from Endor Labs: 43% were command or shell injection. 20% targeted tooling infrastructure. The rest split across path traversal, SSRF, and authentication bypass. These aren’t novel attack categories. They’re the same vulnerability classes OWASP cataloged in 2003, showing up now because MCP servers are effectively web servers that nobody treats as web servers.

Anthropic launched MCP in November 2024 as an open protocol for connecting AI agents to tools and data sources. Adoption was immediate. Within one year: 5,800+ registered MCP servers, 300+ clients, 97 million monthly SDK downloads (PulseMCP, Zuplo State of MCP Report). Every major AI coding tool supports it. Every major cloud provider ships MCP integrations.

Almost nobody audited the security.

BlueRock’s MCP Trust Registry scanned over 8,000 public MCP servers in early 2026. The findings: 36.7% have potential SSRF vulnerabilities. Of 518 servers tested for authentication, 214 (41%) had none at all. Of those that did require credentials, 53% relied on static API keys or personal access tokens. Only 8.5% used OAuth (Zuplo).

You have better authentication on your personal Netflix account than most MCP servers have on the tools your AI agent calls with production credentials.

How does SSRF work when your server is an AI tool provider?

Traditional SSRF tricks a web server into making requests to internal resources on behalf of an attacker. MCP SSRF follows the same principle but the attack chain has an extra link, and that link makes everything worse.

sequenceDiagram
    participant A as Attacker
    participant C as Untrusted Content
    participant AG as AI Agent
    participant M as MCP Server<br/>(cloud credentials)
    participant I as Internal Service /<br/>Cloud Metadata

    A->>C: Embed malicious URL in document
    C-->>AG: Agent processes document
    AG->>M: Calls tool with attacker-controlled URL
    M->>I: Fetches URL (carries managed identity token)
    I-->>M: Returns sensitive data or token
    M-->>AG: Returns result to agent
    AG-->>A: Data exfiltrated via subsequent tool call

The sequence:

  1. An attacker embeds a malicious URL inside content that an AI agent will process. A Figma file, a Confluence page, an email attachment, a code comment.
  2. The agent, following the embedded instruction or confused by it, calls an MCP tool with the attacker-controlled URL as a parameter.
  3. The MCP server, running on your infrastructure with your credentials, fetches that URL.
  4. That request reaches internal services, cloud metadata endpoints like http://169.254.169.254/ on AWS, or attacker-controlled servers that capture tokens.
  5. The agent acts as an unwitting proxy. It has no mechanism to distinguish legitimate tool use from attacker-directed tool abuse.

MCP servers often run with managed identity credentials or service account tokens that carry broad cloud permissions. SSRF doesn’t just reach internal services. It exfiltrates the server’s identity token. One forged request, one stolen token, full cloud account access.

DNS rebinding extends this further. A victim visiting a malicious website can route requests to their local MCP server, triggering command execution with no direct interaction with an AI assistant. This is how the ClawJacked vulnerability (Oasis Security, February 2026) worked: any website could brute-force the local gateway password because the rate limiter exempted localhost requests.

What do the three worst CVEs reveal about MCP’s attack surface?

Three CVEs from early 2026 illustrate the full spectrum of what goes wrong.

CVE-2026-26118: Microsoft Azure MCP (SSRF, CVSS 8.8)

Microsoft patched this on March 10, 2026 during Patch Tuesday. Azure MCP Server tools accepted user-provided parameters as URLs without validation. An attacker supplied a malicious URL instead of a legitimate Azure resource identifier. The server sent an outbound request carrying its managed identity token. Attacker captured the token and used it to access other Azure resources under that service account (Blueinfy).

This is the canonical MCP SSRF pattern: the server trusts tool parameters, the parameters are attacker-influenced, and the server’s credentials travel with the request.

CVE-2026-25049: n8n sandbox escape (RCE, CVSS 9.4)

n8n is a workflow automation platform with 50k+ GitHub stars. The vulnerability exploited a type confusion between TypeScript’s compile-time string enforcement and JavaScript’s runtime behavior. A sanitizer validated input types at compile time. Attackers passed non-string values at runtime using destructuring syntax, bypassing the sandbox entirely.

Impact: unauthenticated RCE via a public webhook. No user interaction required. Full server compromise, credential theft, persistent backdoor installation. This CVE also bypassed the fix for CVE-2025-68613 (patched December 2025), meaning the same attack surface was exploited twice in three months.

The lesson: sandboxes built on language-level type assumptions fail when the runtime doesn’t enforce them. Most MCP servers are JavaScript or Python. Both have this gap between compile-time guarantees and runtime reality.

CVE-2026-27825 + CVE-2026-27826: mcp-atlassian (path traversal + SSRF to RCE)

Pluto Security discovered this in mcp-atlassian, a community MCP server for Jira and Confluence with 4.4K GitHub stars and 4 million downloads. Not an official Atlassian product, but widely deployed.

Two CVEs chained together. CVE-2026-27825 (CVSS 9.1) was an arbitrary file write via the download_attachment tool. The tool accepted an attacker-supplied file path without confining it to a safe base directory. Write to ~/.bashrc or ~/.ssh/authorized_keys, and you own the machine on next login.

CVE-2026-27826 (CVSS 8.2) was SSRF via unvalidated custom HTTP headers (X-Atlassian-Jira-Url, X-Atlassian-Confluence-Url) in middleware. Two HTTP requests, no authentication, root-level RCE for anyone on the local network when MCP HTTP transport binds to 0.0.0.0.

The fix in version 0.17.0 added validate_safe_path() and validate_url_for_ssrf(). Standard AppSec controls that should have existed from day one.

Why are MCP servers the perfect SSRF target?

The root cause goes deeper than individual bugs. The paper “Agentic AI as a Cybersecurity Attack Surface” (arXiv 2602.19555) introduces a concept that explains why MCP’s security model is structurally flawed: the capability-identity gap.

Traditional software has fixed build-time dependencies. You declare them in a manifest, pin versions, verify hashes. Agentic systems don’t work that way. They assemble execution context at runtime through probabilistic semantic decisions. The LLM reads a tool description, decides it matches the user’s intent, and calls it. No cryptographic binding ties what the agent thinks a tool does to what it actually does.

This means:

  • An agent’s effective permissions are unknown at deployment time. The LLM can discover and invoke tools that weren’t part of the original design.
  • Tool identity is semantic, not cryptographic. The agent picks tools by matching natural-language descriptions, which can be poisoned or spoofed.
  • No revocation mechanism exists. If a tool is compromised, there’s no certificate to revoke, no hash to invalidate.

The paper calls this “stochastic dependency resolution.” Agentic systems resolve their dependencies probabilistically at runtime rather than deterministically at build time. This is the fundamental difference from traditional software supply chains, and it’s why standard dependency scanning tools miss the problem entirely.

For more on how data leakage compounds this risk, see Data leakage prevention.

What does the OWASP MCP Top 10 say?

OWASP released the MCP Top 10 in early 2026, currently in beta (Phase 3). It’s separate from both the LLM Top 10 and the Agentic Top 10. Led by Vandana Verma Sehgal under the GenAI Security Project.

# Risk What it means
MCP01 Token mismanagement and secret exposure Static API keys, hardcoded credentials, tokens with excessive scope
MCP02 Privilege escalation via scope creep Tools gaining permissions beyond their declared scope at runtime
MCP03 Tool poisoning Malicious tool descriptions that manipulate agent behavior
MCP04 Supply chain attacks and dependency tampering Compromised MCP servers or skills injecting malicious code
MCP05 Command injection and execution Unsanitized inputs passed to shell commands or interpreters
MCP06 Intent flow subversion Prompt injection via contextual payloads in tool inputs/outputs
MCP07 Insufficient authentication and authorization Missing or weak auth on MCP server endpoints
MCP08 Lack of audit and telemetry No logging of tool invocations, impossible incident response
MCP09 Shadow MCP servers Unauthorized MCP servers on the network that agents discover and use
MCP10 Context injection and over-sharing Agents leaking sensitive context to MCP servers that don’t need it

The three CVEs from the previous section map directly. Azure CVE-2026-26118 hits MCP01 (managed identity token exposed via SSRF) and MCP07 (no input validation). n8n CVE-2026-25049 hits MCP05 (command injection via sandbox escape). mcp-atlassian hits MCP04 (supply chain via community package) and MCP05 (path traversal to RCE).

If your team adopts one thing from this list, make it MCP07. Forty-one percent of MCP servers have no authentication. Fix that first.

How do you harden an MCP deployment?

A checklist drawn from OWASP’s Secure MCP Server Development Guide, NVIDIA’s sandboxing guidance, and the patches that fixed the three CVEs above.

Authentication (MCP01, MCP07)

Stop using static API keys. The current state of 53% on static keys and 8.5% on OAuth is not defensible.

# MCP server config: OAuth 2.1 with scoped tokens
auth:
  type: oauth2
  issuer: https://auth.yourcompany.com
  audience: mcp-server-prod
  scopes:
    - tools:read
    - tools:execute
  token_lifetime: 3600  # 1 hour max
  refresh: false  # no long-lived sessions

Use a credential broker that issues short-lived tokens per agent session. Never bake credentials into the MCP server image.

Input validation (MCP05, MCP06)

Every tool parameter that accepts a URL or file path needs validation. The mcp-atlassian v0.17.0 fix is the reference pattern:

import ipaddress
from urllib.parse import urlparse

ALLOWED_SCHEMES = {"https"}
BLOCKED_HOSTS = {
    "localhost", "127.0.0.1", "0.0.0.0",
    "metadata.google.internal",
}

def validate_url_for_ssrf(url: str) -> bool:
    """Block SSRF via URL parameter injection."""
    parsed = urlparse(url)
    if parsed.scheme not in ALLOWED_SCHEMES:
        return False
    if parsed.hostname in BLOCKED_HOSTS:
        return False
    try:
        ip = ipaddress.ip_address(parsed.hostname)
        if ip.is_private or ip.is_loopback or ip.is_link_local:
            return False
    except ValueError:
        pass  # hostname is not an IP, proceed
    return True


def validate_safe_path(base_dir: str, requested_path: str) -> str:
    """Confine file operations to a safe base directory."""
    import os
    real_base = os.path.realpath(base_dir)
    real_path = os.path.realpath(os.path.join(base_dir, requested_path))
    if not real_path.startswith(real_base):
        raise ValueError(f"Path traversal blocked: {requested_path}")
    return real_path

Network isolation (SSRF class)

Run MCP servers in hardened containers with explicit egress rules:

# Docker Compose: MCP server with network restrictions
services:
  mcp-server:
    image: your-mcp-server:latest
    networks:
      - mcp-internal
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp
    environment:
      - MCP_BIND_ADDRESS=127.0.0.1  # never 0.0.0.0
      - MCP_ALLOWED_ORIGINS=https://your-agent.internal

networks:
  mcp-internal:
    driver: bridge
    internal: true  # no external egress by default

Block outbound requests to cloud metadata endpoints (169.254.169.254) at the network level, not the application level. Application-level blocks can be bypassed via DNS rebinding.

Audit logging (MCP08)

Log every tool invocation with parameters, caller identity, and timestamp. If you can’t reconstruct what your agent did last Tuesday, you can’t do incident response. For production observability patterns, see Observability and tracing.

Scanning

Tencent’s AI-Infra-Guard scans for 14 categories of MCP security risks using a ReAct-based agent that drives the assessment. It covers malicious tool descriptions, delayed behavior changes, tool hijacking, code execution vulnerabilities, data exfiltration, and authentication bypass. Run it against your MCP servers before deploying them.

Takeaways

  • 30+ CVEs in 60 days. MCP servers are web servers with cloud credentials and no security review process.
  • 36.7% of public MCP servers have SSRF vulnerabilities. 41% have no authentication. 53% use static API keys.
  • The capability-identity gap means agents resolve tool dependencies probabilistically at runtime, creating an attack surface traditional dependency scanning misses.
  • The three CVEs (Azure SSRF, n8n sandbox escape, mcp-atlassian path traversal) are textbook AppSec failures repackaged in a new protocol context.
  • OWASP MCP Top 10 is the starting framework. Prioritize MCP07 (authentication) and MCP01 (credential management) first.
  • Harden with OAuth 2.1, URL/path validation, network isolation, audit logging, and container sandboxing.

Further reading

Want to work together?

I take on projects, advisory roles, and fractional CTO engagements in AI/ML. I also help businesses go AI-native with agentic workflows and agent orchestration.

Get in touch

Related across topics

Prompt Injection Defense

8 minute read

“Treat prompts like an attack surface: isolate untrusted content, validate every tool call, and fail closed under uncertainty.”