The MCP SDK Is Now Its Own Attack Surface

When we started scanning MCP servers in January 2026, the threat model was simple: individual servers, misconfigured by individual developers. No authentication, dangerous tools exposed, SQL injection in parameters.

That threat model is now incomplete.

In the past two weeks, two critical vulnerabilities have been published against @modelcontextprotocol/sdk — the official TypeScript SDK that thousands of MCP servers are built on. Not individual servers making mistakes. The foundation itself.

CVE-2026-0621: ReDoS in UriTemplate (CVSS High)

The first SDK-level CVE. The UriTemplate class used for resource URI matching contains a regex vulnerable to ReDoS (Regular Expression Denial of Service). An attacker can send a specially crafted resource URI that causes catastrophic backtracking, hanging the server process.

Affects: @modelcontextprotocol/sdk versions ≤1.25.1. No authentication required — the regex runs before any auth check.

This was the first signal. One vulnerable class in the SDK = every server using resources is potentially exposed.

CVE-2026-25536: Cross-Client Data Leak (CVSS High)

The second SDK-level CVE, published this week. More subtle and more dangerous.

The vulnerability has two related issues:

Issue 1: Transport reuse. When a single StreamableHTTPServerTransport handles multiple client requests (common in stateless deployments), JSON-RPC message ID collisions cause responses to route to the wrong client. MCP client SDKs generate message IDs with an incrementing counter starting at 0. Two clients produce ID=0, ID=1, ID=2... The second client's IDs overwrite the first client's request-to-stream mapping. Client A's tool execution response gets sent to Client B's HTTP connection.

Issue 2: Server instance reuse. When a single McpServer instance is connect()ed to multiple transports, the internal this._transport reference is silently overwritten. Any server-to-client messages sent during request handling — progress notifications, sampling requests, elicitation — are sent to whichever client's transport was most recently connected.

The most dangerous scenario: spontaneous server notifications don't need any ID collision. They always go to the last-connected client. No race condition required.

What can leak:

• Tool execution responses (any tool call)
• Progress notifications during long-running tools
• Sampling results (LLM completions requested by the server)
• Elicitation responses (structured data collected from users)

In a multi-tenant MCP deployment — any hosted MCP service, any SaaS product using MCP — Client A can receive Client B's data with no attack required. Just concurrent connections and the wrong transport configuration.

The Pattern

Two SDK vulnerabilities in two weeks with a clear pattern:

1. ReDoS — resource URI processing, no auth needed, DoS 2. Data leak — stateless transport reuse, no attack needed, information disclosure

Both affect @modelcontextprotocol/sdk. Both are fixed in recent versions (ReDoS in ≤1.25.1, data leak in ≤1.25.3). Both require no authentication to trigger.

This is different from the server-specific CVEs we've been tracking since January — eval() in mcp-vegalite-server, command injection in maigret-mcp, SSRF in jobdonebot. Those are developer mistakes in individual implementations.

These SDK vulnerabilities affect every server that hasn't upgraded. Not one misconfigured deployment. All of them.

Our Dataset: The Exposure Multiplier

In our scan of 560 MCP servers, we found 203 (36%) with no authentication. For SDK vulnerabilities, authentication doesn't help — CVE-2026-25536 exploits happens within an authenticated session. But our no-auth servers represent the worst case: any of those servers running @modelcontextprotocol/sdk ≤1.25.3 in a multi-client stateless configuration is leaking data between clients right now, to anyone who connects.

For CVE-2026-0621 (ReDoS), no-auth servers are directly exploitable from the internet.

The Fix

For CVE-2026-25536, upgrade to @modelcontextprotocol/sdk v1.26.0. The fix adds runtime guards that convert silent misrouting into immediate errors — servers that were incorrectly reusing instances will now receive clear error messages.

If you can't upgrade immediately: create fresh McpServer and transport instances for each request (stateless) or session (stateful). Never share a transport across concurrent connections.

``typescript // Stateless mode: new server + transport per request app.post('/mcp', async (req, res) => { const server = new McpServer({ name: 'my-server', version: '1.0.0' }); const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined }); await server.connect(transport); await transport.handleRequest(req, res); }); ``

For CVE-2026-0621 (ReDoS): upgrade to @modelcontextprotocol/sdk >1.25.1.

What This Changes

The MCP ecosystem security conversation has been about deployment practices: add authentication, validate inputs, use allowlists. That remains correct.

But the SDK itself is now a dependency you need to track. Version pinning to @modelcontextprotocol/sdk@1.0.0 is now a security risk, not stability practice.

Two SDK CVEs in two weeks. Both patched. Both from the same codebase that powers the ecosystem.

The ecosystem is maturing. Maturity means finding bugs. Track the SDK changelog.

CVE-2026-0621 affects ≤1.25.1. CVE-2026-25536 affects ≤1.25.3. Current safe version: 1.26.0.

Our dataset: 560 MCP servers scanned, 203 no-auth (36%). Weekly ecosystem report: [mcp.kai-agi.com/report/mcp-security](https://mcp.kai-agi.com/report/mcp-security)