@modelcontextprotocol/sdk has cross-client data leak via shared server/transport instance reuse

• 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.

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's transport

How to tell if you're affected

• You use sessionIdGenerator (stateful mode) with a new McpServer per session → not affected by either issue. Each session has its own transport and server instance.
• You use sessionIdGenerator but share a single McpServer across sessions → not affected by Issue 1 (transport re-use), but affected by Issue 2 (server re-use) if your tools send progress notifications, sampling, or elicitation during execution.
• You are in stateless mode and reuse both a transport and a server across requests → affected by both issues; all request types can leak.
• You are in stateless mode and create a new transport per request, but reuse the server → affected by Issue 2 only; safe if your tools only return results without sending progress notifications, sampling, or elicitation during execution.
• You create a new server + transport per request → not affected.
• Single-client environments (e.g., local development with one IDE) → not affected.

Patches

The fix (v1.26.0) adds runtime guards that turn silent data misrouting into immediate, actionable errors:

1. Protocol.connect() now throws if the protocol is already connected to a transport, preventing silent transport overwriting (addresses Issue 2)
2. Stateless StreamableHTTPServerTransport.handleRequest() now throws if called more than once, enforcing one-request-per-transport in stateless mode (addresses Issue 1)
3. In-flight request handler abort controllers are cleaned up on close(), and sendNotification/sendRequest in handler extras check the abort signal before sending, preventing messages from leaking after a transport is replaced

Servers that were incorrectly reusing instances will now receive a clear error message directing them to create separate instances per connection.

Workarounds

If you cannot upgrade immediately, ensure your server creates fresh McpServer and transport instances for each request (stateless) or session (stateful):

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

// Stateful mode: create new server + transport per session
const sessions = new Map();
app.post('/mcp', async (req, res) => {
  const sessionId = req.headers['mcp-session-id'];
  if (sessions.has(sessionId)) {
    await sessions.get(sessionId).transport.handleRequest(req, res);
  } else {
    const server = new McpServer({ name: 'my-server', version: '1.0.0' });
    // ... register tools, resources, etc.
    const transport = new StreamableHTTPServerTransport({
      sessionIdGenerator: () => randomUUID()
    });
    await server.connect(transport);
    sessions.set(transport.sessionId, { server, transport });
    await transport.handleRequest(req, res);
  }
});