MCP TypeScript SDK: Cross-Client Data Leak via Transport Instance Reuse (CVE-2026-25536)
When a single McpServer instance with a StreamableHTTPServerTransport is reused across multiple client connections, response data leaks across client boundaries. One client receives tool output intended for another. This is the canonical multi-tenant MCP deployment mistake: the SDK permits instance reuse but the transport state is not isolated per client. The flaw affects versions 1.10.0 through 1.25.3 of the official TypeScript SDK, a window spanning roughly fifteen months of production deployments. Six public PoC exploits are catalogued on GitHub. The fix in 1.26.0 adds runtime guards that convert silent misrouting into an immediate error.
What happened
Anthropic's MCP TypeScript SDK implements the Streamable HTTP transport as a stateful object that manages connection context. In a single-client deployment, one McpServer instance handles one client and the state is straightforward. In a multi-client stateless deployment, the common pattern is to instantiate a server once and reuse it across incoming connections.
That reuse pattern is the bug. The StreamableHTTPServerTransport maintains per-session state that is not isolated between concurrent clients. When a response is produced for client A, that response can be routed to client B if the transport's session context is in an ambiguous state. One client receives tool output, credentials, or sensitive data that was generated for a different client entirely.
The vulnerability is classified as CWE-362 (Race Condition on Shared Resource). The root cause is the transport not enforcing a one-transport-instance-per-session contract that the server's session model implicitly requires.
The fix in SDK version 1.26.0 adds runtime guards that detect incorrect instance reuse and immediately raise errors rather than silently misrouting responses. Any server incorrectly reusing instances will surface configuration errors after the upgrade, making the misconfiguration visible rather than silent. Six public PoC exploits exist for the pre-patch behaviour.
The PolicyLayer angle
Cross-client data leakage in a multi-tenant MCP deployment is a confidentiality failure with no recovery path after the fact. A client that receives another client's tool output has already seen the data. The leak is silent by design on unpatched versions. The standard assumption that "responses go to the right client" does not hold.
The relevant policy controls for multi-tenant MCP infrastructure: enforce one transport instance per session as an architectural constraint enforced at the infrastructure level, not left to individual server authors; audit every multi-client deployment for the instance-reuse pattern before upgrading, because the upgrade will reveal misconfigurations as errors that may break workflows; treat response routing as a security property, not a performance optimisation. The fix converts silent misrouting into an error. For any production deployment that was running the affected versions in multi-client mode, the correct posture is to assume cross-client data exposure occurred and to audit what tool outputs those clients received during the vulnerable window.
Mitigations
Upgrade @modelcontextprotocol/sdk to version 1.26.0 or later, and mcp-handler to 1.1.0 or later. If upgrade is not immediately possible, create a fresh McpServer and transport instance for each request (stateless) or session (stateful) rather than reusing instances across clients. After upgrading, any servers incorrectly reusing instances will produce errors; resolve those configuration issues before returning to production. For deployments that ran the affected versions in multi-client mode, audit logs for evidence of cross-client tool output delivery.
FAQs
No. The leak only occurs when a single McpServer and transport instance is reused across multiple concurrent client connections. Single-client deployments and deployments that correctly create a fresh server and transport per session are not affected.
Common enough that the SDK patch was required. A scan of 560 MCP servers found 36% running with no authentication, meaning those servers were likely using stateless deployment patterns where instance reuse is the default. The affected version range spans 1.10.0 through 1.25.3, a window of roughly fifteen months of SDK releases.
Yes, deliberately. The fix converts the silent misrouting into an immediate error. Any server that was incorrectly reusing instances will start throwing errors after the upgrade, revealing the misconfiguration. Deployments using the correct pattern of one instance per session are unaffected.