Thirty CVEs in sixty days. Between January and February 2026, the Model Context Protocol went from “promising integration standard” to “the fastest-growing attack surface in the AI stack.” The CVEs were not theoretical findings buried in academic papers. They included a CVSS 9.6 remote code execution flaw in a package with 437,000+ downloads, an Azure MCP SSRF that let attackers steal managed identity tokens, and Token Security demonstrating a fully zero-click RCE chain at RSAC 2026 where a crafted Google Docs file could harvest cloud secrets without any user interaction.
The 60-day burst was not random. It was the inevitable result of a protocol reaching 10,000+ public server implementations before anyone systematically audited what those servers actually exposed. BlueRock scanned 7,000 MCP servers and found 36.7% vulnerable to SSRF. Qualys declared MCP servers “the new shadow IT.” And CoSAI published a whitepaper mapping 12 threat categories and 40 distinct threats that most organizations are not addressing.
Why 30 CVEs Happened in 60 Days
The vulnerability burst was not about researchers suddenly deciding to look at MCP. Three structural factors converged in early 2026 that made this inevitable.
The Anthropic Reference Implementation Problem
In January 2026, security researcher Yarden Porat disclosed three CVEs in Anthropic’s own mcp-server-git: CVE-2025-68143 (CVSS 8.8), CVE-2025-68144 (CVSS 8.1), and CVE-2025-68145 (CVSS 7.1). The core issue: the --repository flag, supposed to restrict file operations to a specific directory, was never enforced. Anthropic’s fix for git_init was to remove the tool entirely.
This matters beyond the specific bugs. Hundreds of third-party MCP servers were built by copying patterns from Anthropic’s reference implementations. When the reference code had missing input validation and absent path boundary checks, those patterns propagated across the ecosystem. The 30 CVEs were not 30 independent bugs; they were variations on the same architectural shortcuts, replicated across different codebases.
The SDK Response Leakage Flaw
CVE-2026-25536 (CVSS 7.1) hit the official MCP TypeScript SDK itself, not a third-party server. When a single McpServer instance with StreamableHTTPServerTransport handled multiple client connections, JSON-RPC message ID collisions caused responses to route to the wrong client. Client A’s data ended up in Client B’s session. This is the kind of bug that turns a shared MCP deployment into a cross-tenant data leak, and it affected versions 1.10.0 through 1.25.3.
For any enterprise running a centralized MCP gateway (exactly the architecture many vendors recommend), this was a wake-up call: the SDK itself could not safely handle the multi-tenant pattern.
43% of CVEs Were Shell Injection
Endor Labs analyzed 2,614 MCP implementations and found that 43% of CVEs involved exec/shell injection. Not novel AI attacks. Classic CWE-78 and CWE-94 vulnerabilities that OWASP has documented for decades. The difference: MCP’s architecture passes LLM-generated strings to system operations by design. Every unvalidated input becomes a potential injection vector when the protocol’s entire purpose is to let AI agents execute tool calls.
The breakdown tells the story:
- 43% exec/shell injection (CWE-78, CWE-94)
- 36.7% Server-Side Request Forgery (SSRF)
- 10% path traversal (CWE-22)
- 7% Cross-Site Scripting (CWE-79)
- 6% SQL injection (CWE-89)
These are the same vulnerability classes from 2005, now running inside AI agent integrations with access to cloud credentials, databases, and internal APIs.
MCPwned: The Zero-Click Chain That Changes the Threat Model
Token Security researcher Ariel Simon presented MCPwned at RSAC 2026, demonstrating what happens when MCP vulnerabilities are chained with the implicit trust that AI agents place in their tools.
The attack starts with a crafted Google Docs file. An IDE coding agent (like Cursor or Claude Code) fetches the document as context. The document contains hidden instructions that direct the agent to connect to an attacker-controlled MCP server. The malicious server returns a tool response containing a Python payload. The agent executes it. Cloud secrets, environment variables, and API keys are harvested. Total user interaction required: zero.
This is not hypothetical. Simon demonstrated the full chain against CVE-2026-26118, the Azure MCP Server SSRF (CVSS 8.8) that Microsoft patched in its March 2026 Patch Tuesday. The vulnerability let an authorized attacker exploit SSRF to capture the MCP Server’s managed identity token, gaining whatever Azure permissions that identity held. Combined with the MCPwned chain, an attacker could go from “a shared document” to “full Azure environment access” without the target clicking anything.
MCP Servers as the New Shadow IT
Qualys TotalAI’s March 2026 analysis called MCP servers “the new shadow IT for AI,” and the framing is accurate. Developers spin up MCP servers to connect their AI coding assistants to internal tools, databases, and APIs. Most of these deployments happen outside the security team’s visibility. No inventory. No authentication audit. No network segmentation review.
The Qualys research identified three layers of exposure:
Network-level discovery gaps. MCP servers run on non-standard ports, often behind developer workstations or CI/CD pipelines. Traditional network scanning tools do not flag them as services requiring security review.
Host-level privilege creep. MCP servers typically run with the same permissions as the developer’s user account. When that account has AWS credentials, database connection strings, or production API keys in its environment, every MCP server inherits that access.
Supply chain opacity. The average MCP deployment pulls in 3-5 community-built servers from npm or GitHub. BlueRock’s scan of 7,000 servers found that most lack any form of authentication, and 36.7% are vulnerable to SSRF out of the box.
This maps directly to what CoSAI’s whitepaper documented when it identified 12 threat categories and 40 specific threats in the MCP ecosystem. The three most common: unauthenticated tool invocation, credential leakage through tool responses, and data exfiltration via crafted tool descriptions (tool poisoning).
What Enterprise Teams Should Do Now
The good news: the vulnerability classes in MCP are well-understood. The bad news: the default posture of most MCP deployments is “wide open.” Here is a concrete remediation checklist based on the CoSAI framework and vendor guidance from Red Hat and Palo Alto Networks.
Inventory Every MCP Server
You cannot secure what you cannot see. Use Qualys TotalAI or equivalent tools to discover MCP servers across your network, host, and supply chain. Check developer workstations, CI/CD runners, and any machine running an AI coding assistant. If you find MCP servers you did not know about, you have a shadow IT problem that needs immediate attention.
Enforce Authentication on Every Endpoint
Only 8.5% of MCP servers implement OAuth, and 38-41% have no authentication at all. Every MCP server in your environment needs authentication. Use BlueRock’s MCP Trust Registry to maintain an approved server list and block unapproved connections.
Validate All Inputs at the Server Boundary
The 43% shell injection rate exists because MCP servers pass LLM-generated strings directly to system calls. Every MCP server tool handler must validate and sanitize inputs before executing any operation. Treat all tool call parameters as untrusted user input, because that is exactly what they are.
Pin SDK Versions and Scan Dependencies
CVE-2026-25536 in the MCP TypeScript SDK shows that the protocol’s own libraries can introduce vulnerabilities. Pin your SDK versions, run Snyk Agent Scan or equivalent tools against your MCP dependencies, and subscribe to the MCP GitHub security advisories.
Segment MCP Network Access
MCP servers should not have access to your entire internal network. Apply least-privilege network policies: restrict outbound connections to only the specific services each server needs. This prevents SSRF attacks from pivoting through MCP servers to reach internal metadata endpoints, cloud credential services, or databases.
The Structural Problem MCP Has Not Solved
The 30 CVEs in 60 days exposed a gap that no patch cycle can fully address: MCP’s trust model assumes that tool descriptions are honest and that servers behave as advertised. There is no built-in mechanism for verifying tool integrity, no cryptographic signing of tool schemas, and no way for a client to confirm that a server’s behavior matches its description.
Anthropic’s MCP specification defines the transport and message format but leaves authentication, authorization, and tool verification entirely to implementers. When 10,000+ servers are built by different teams with different security priorities, the result is predictable: the weakest implementations set the effective security bar for the ecosystem.
CoSAI’s 12 threat categories map this structural gap precisely. The most fundamental: tool description integrity (no way to verify a tool does what it claims), credential boundary enforcement (servers inherit host credentials by default), and multi-tenant isolation (the SDK itself had the CVE-2026-25536 response leakage bug).
Until MCP gets mandatory authentication, cryptographic tool signing, and built-in tenant isolation, these 30 CVEs are a preview, not a conclusion. The protocol is useful. The protocol is widely adopted. And the protocol’s security surface is growing faster than the community’s ability to secure it.
Frequently Asked Questions
What caused 30 MCP CVEs to be filed in just 60 days?
Three factors converged: Anthropic’s reference implementations had missing input validation that was copied across hundreds of third-party servers, the MCP TypeScript SDK itself had a multi-tenant response leakage bug (CVE-2026-25536), and the protocol reached 10,000+ public server implementations before systematic security auditing caught up. 43% of the CVEs were classic shell injection vulnerabilities.
What is MCPwned and how does the zero-click attack work?
MCPwned is vulnerability research by Token Security presented at RSAC 2026. It demonstrates a zero-click RCE chain where a crafted Google Docs file triggers an IDE coding agent to connect to an attacker-controlled MCP server, execute a Python payload, and harvest cloud secrets. No user interaction is required. The attack exploits the implicit trust AI agents place in MCP tool responses.
What percentage of MCP servers are vulnerable to SSRF?
BlueRock scanned over 7,000 MCP servers and found that 36.7% have potential SSRF vulnerabilities. This includes the Microsoft MarkItDown MCP server and the Azure MCP Server (CVE-2026-26118, CVSS 8.8), which could be exploited to steal managed identity tokens and gain unauthorized access to Azure resources.
Why does Qualys call MCP servers “the new shadow IT”?
Developers spin up MCP servers to connect AI coding assistants to internal tools and APIs, typically outside the security team’s visibility. These servers run on non-standard ports, inherit the developer’s credentials and permissions, and pull in community-built dependencies with no authentication. Most organizations have no inventory of MCP servers running in their environment.
How can enterprises protect against MCP security vulnerabilities?
Key steps include: inventory all MCP servers using tools like Qualys TotalAI, enforce authentication on every endpoint (only 8.5% of MCP servers implement OAuth), validate all inputs at the server boundary to prevent shell injection, pin SDK versions and scan dependencies, and segment MCP server network access using least-privilege policies. The CoSAI whitepaper provides a comprehensive framework mapping 12 threat categories and 40 specific threats.