@modelcontextprotocol/sdk has cross-client data leak via shared server/transport instance reuse
High7.1CVE-2026-25536 · Published Feb 4, 2026 · updated Sep 10, 2026
### Summary Cross-client data leak via two distinct issues: (1) reusing a single `StreamableHTTPServerTransport` across multiple client requests, and (2) reusing a single `McpServer`/`Server` instance across multiple transports. Both are most common in stateless deployments. ### Impact This advisory covers two related but distinct vulnerabilities. A deployment may be affected by one or both. #### Issue 1: Transport re-use **What happens:** When a single `StreamableHTTPServerTransport` instance handles multiple client requests, JSON-RPC message ID collisions cause responses to be routed to the wrong client's HTTP connection. The transport maintains an internal `requestId → stream` mapping, and since MCP client SDKs generate message IDs using an incrementing counter starting at 0, two clients produce identical IDs. The second client's request overwrites the first client's mapping entry, routing the response to the wrong HTTP stream. **What is affected:** All request types , `tools/call`, `resources/read`, `prompts/get`, etc. No server-initiated features are required to trigger this. **Conditions:** - A single `StreamableHTTPServerTransport` instance is reused across multiple ...
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| @modelcontextprotocol/sdk npm | >= 1.10.0, < 1.26.0 | 1.26.0 |
Details and references
### Summary Cross-client data leak via two distinct issues: (1) reusing a single `StreamableHTTPServerTransport` across multiple client requests, and (2) reusing a single `McpServer`/`Server` instance across multiple transports. Both are most common in stateless deployments. ### Impact This advisory covers two related but distinct vulnerabilities. A deployment may be affected by one or both. #### Issue 1: Transport re-use **What happens:** When a single `StreamableHTTPServerTransport` instance handles multiple client requests, JSON-RPC message ID collisions cause responses to be routed to the wrong client's HTTP connection. The transport maintains an internal `requestId → stream` mapping, and since MCP client SDKs generate message IDs using an incrementing counter starting at 0, two clients produce identical IDs. The second client's request overwrites the first client's mapping entry, routing the response to the wrong HTTP stream. **What is affected:** All request types , `tools/call`, `resources/read`, `prompts/get`, etc. No server-initiated features are required to trigger this. **Conditions:** - A single `StreamableHTTPServerTransport` instance is reused across multiple client requests (most common in stateless mode without `sessionIdGenerator`) - Two or more clients send requests concurrently - Clients generate overlapping JSON-RPC message IDs (the SDK's default client uses an incrementing counter starting at 0) #### Issue 2: Server/Protocol re-use **What happens:** When a single `McpServer` (or `Server`) instance is `connect()`ed to multiple transports (one per client), the Protocol's internal `this._transport` reference is silently overwritten. The final response to a request is routed correctly (the Protocol captures the transport reference at request time), but any **server-to-client messages sent during request handling** use the shared `this._transport` reference, which may point to a different client's transport. **What is affected:** This depends on what features your server uses: - **Final responses** (the return value from a tool/resource/prompt handler): Affected in most cases. The Protocol captures this._transport at [request-handling time](https://github.com/modelcontextprotocol/typescript-sdk/blob/main/packages/core/src/shared/protocol.ts#L760), not the transport that delivered the request. This means: - If a request is already in-flight when a second connect() occurs (i.e., the request arrived before the transport was overwritten), the captured reference is correct and the response routes properly. - If a request arrives on the old transport after a second connect() has overwritten this._transport, the captured reference points to the new transport, and the response is mis-routed. The requesting client will time out. - **Progress notifications** sent during tool execution via `sendNotification`: **Affected.** These are dispatched through `this._transport`. When the transport has been overwritten and message IDs collide on the new transport, notifications are routed to the wrong client's HTTP stream. - **Sampling** (`createMessage`) and **elicitation** requests sent during tool execution via `sendRequest`: **Affected.** Same mechanism , the request is sent to the wrong client. - **Spontaneous server-initiated notifications** (outside any request handler): **Affected.** These are sent to whichever client's transport was most recently connected. **Conditions:** - A single `McpServer`/`Server` instance is `connect()`ed to multiple transports across requests or sessions - Two or more clients connect concurrently - For in-request notifications/requests: message ID collision on the other transport is required for silent data leaking (the SDK's default client uses an incrementing counter starting at 0). Without collision, the transport will throw an error rather than misroute. - For spontaneous notifications: no collision needed, messages are always sent to the last-connected client'
- CVSS 3.1
- CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N
- Severity from
- GitHub (reviewed advisory)
- Weakness
- CWE-362
- Also known as
- CVE-2026-25536
More MCP SDKs advisories
All MCP SDKs| Date | Advisory | Severity | Fixed in |
|---|---|---|---|
| Jul 16 | MCP Python SDK: WebSocket server transport does not support Host/Origin validation | High | 1.28.1 |
| Jul 16 | MCP Python SDK: HTTP transports serve session requests without verifying the authenticated principal | High7.1 | 1.27.2 |
| Jul 16 | MCP Python SDK: Experimental task handlers allow any client to access and cancel other clients' tasks | High7.6 | 1.27.2 |
| Jan 5 | Anthropic's MCP TypeScript SDK has a ReDoS vulnerability | High | 1.25.2 |
| Dec 22025 | Model Context Protocol (MCP) Python SDK does not enable DNS rebinding protection by default | High | 1.23.0 |
| Dec 22025 | Model Context Protocol (MCP) TypeScript SDK does not enable DNS rebinding protection by default | High | 1.24.0 |