The official Model Context Protocol TypeScript SDK (@modelcontextprotocol/sdk) versions 1.10.0 through 1.25.3 contain a cross-client data leakage vulnerability tracked as CVE-2026-25536 (CVSS 7.1). The flaw enables one MCP client to receive tool results intended for a different client when server instances or transports are shared across connections — a pattern common in stateless and serverless deployments.
What Happened
Two distinct issues underpin CVE-2026-25536, both documented in GitHub Security Advisory GHSA-345p-7cg4-v4c7:
- StreamableHTTPServerTransport reuse — When a single
StreamableHTTPServerTransportinstance is reused across multiple HTTP requests, responses can be delivered to the wrong client. - McpServer/Server instance reuse — When a single
McpServerorServerinstance is shared across multiple transports, internal state bleeds between client sessions.
Both paths are most likely to appear in stateless deployments — Vercel Serverless Functions, Node.js API routes, and similar environments where request handlers commonly instantiate a single MCP server and reuse it across incoming connections for efficiency.
Impact
In multi-tenant MCP deployments, Client A may receive Client B’s tool results. Because MCP tool results can contain sensitive data — API responses, database query results, file contents, credentials — the data leak risk is real and significant. The vulnerability does not require authentication or attacker-controlled input; it arises from the SDK’s internal response routing when instances are shared.
Affected deployments include:
- Any MCP server using
@modelcontextprotocol/sdkv1.10.0–v1.25.3 with shared server/transport instances - Vercel Serverless Functions running MCP endpoints
- Node.js stateless MCP server deployments behind load balancers
- Any deployment pattern that instantiates one
McpServerand attaches multiple transports
Root Cause: Stateful Objects in Stateless Contexts
The MCP TypeScript SDK’s StreamableHTTPServerTransport and McpServer are stateful by design — they track request IDs, sessions, and response correlation internally. When these objects are created once and reused for every incoming request (a common pattern in serverless and API-route handlers), the internal state machines overlap. Response messages intended for Client A’s request are matched to Client B’s pending request ID and delivered through Client B’s transport.
This is not a race condition in the traditional sense — it is an architectural mismatch between the SDK’s object model (designed for one-server-per-client) and the deployment pattern (one-server-many-clients) that stateless frameworks naturally encourage.
Patch and Mitigation
The fix is available in @modelcontextprotocol/sdk v1.26.0 and later. The patched version ensures each transport gets its own server instance, preventing cross-client response delivery.
If immediate upgrade is not possible, operators can mitigate by:
- Creating a new
McpServerinstance per client connection rather than sharing one across requests - Creating a new
StreamableHTTPServerTransportper request in stateless handlers - Implementing response correlation checks on the client side to detect mismatched results
- Running MCP servers behind connection-scoped proxies that enforce one-server-per-session
Operator Checklist
- Identify all services using
@modelcontextprotocol/sdkand check the version (npm list @modelcontextprotocol/sdk). - If the version is 1.10.0–1.25.3, upgrade to 1.26.0+ immediately.
- Audit deployment patterns: grep for
new McpServer()ornew Server()calls that are created at module scope and reused across requests. - If serverless/stateless patterns cannot be changed, ensure each request creates its own
McpServer+StreamableHTTPServerTransportpair. - Review logs for any evidence of unexpected cross-client data in tool responses.
- Rotate any API keys, tokens, or credentials that may have been exposed through leaked responses.
Broader Context
CVE-2026-25536 is the latest in a series of MCP security disclosures in 2026. The vulnerability highlights a recurring theme in the MCP ecosystem: the gap between the protocol’s single-client design assumptions and the multi-tenant reality of production deployments. As MCP adoption grows beyond local developer tools into server-side and cloud-hosted environments, this class of shared-state vulnerability will continue to surface unless SDKs and deployment guides explicitly address session isolation.
The Vulnerable MCP Project (vulnerablemcp.info) tracks this CVE alongside dozens of other MCP-related vulnerabilities, providing a centralized resource for operators monitoring the ecosystem’s security posture.
Summary
| Field | Detail |
|---|---|
| CVE | CVE-2026-25536 |
| CVSS | 7.1 (High) |
| Affected Package | @modelcontextprotocol/sdk |
| Affected Versions | 1.10.0 – 1.25.3 |
| Patched Version | 1.26.0+ |
| Advisory | GHSA-345p-7cg4-v4c7 |
| Attack Vector | Network / Shared-instance reuse |
| Impact | Cross-client data leakage in multi-tenant deployments |
This article is part of MCPwatch.tech’s ongoing coverage of Model Context Protocol security. Follow us for neutral, source-linked analysis of MCP vulnerabilities, threats, and hardening guidance.