Description

The Model Context Protocol TypeScript SDK provides TypeScript client and server implementations of the Model Context Protocol. From 2.0.0 until 2.3.0 in @modelcontextprotocol/server, applications that shared one stateless HTTP transport or one McpServer or Server instance among multiple clients could deliver responses and notifications to the wrong client. The affected surface is an MCP server reached over HTTP by multiple clients. The trigger is reuse of one stateless transport or server instance. Messages were associated with a connection using only the JSON-RPC request identifier. SDK clients start request identifiers at zero, so collisions occur in normal operation. Cross-client delivery exposes one client's responses and notifications to another client. The issue requires an HTTP endpoint reachable by more than one client and an application that constructs the server or transport once at startup instead of once per request or session. stdio servers and factory-created per-call servers are not affected. Upgrading causes reused instances to fail and therefore requires an application code change. This issue is fixed in @modelcontextprotocol/server 2.3.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.7",
  "pubDate": "2026-11-05T22:17:45.817Z",
  "pubdate": "2026-11-05T22:17:45.817Z",
  "executiveSummary": "The Model Context Protocol (MCP) TypeScript SDK is vulnerable to an information disclosure and message interception flaw due to improper handling of stateless HTTP transport connections.\nThis vulnerability occurs in @modelcontextprotocol/server versions 2.0.0 through 2.3.0 when a single server or transport instance is shared across multiple concurrent clients.\nThe root cause is a flawed message association mechanism that relies solely on JSON-RPC request identifiers, which are predictable and reset to zero by default in SDK clients.\nWhen multiple clients interact with the same HTTP endpoint, the server misroutes incoming responses and notifications to the wrong recipient.\nThis allows a malicious or unintentional client to receive data intended for another client, leading to significant privacy breaches, potential command injection scenarios, or leakage of sensitive context information.\nExploitation requires the application to instantiate the server or transport once at startup rather than per-session, and involves simultaneous connections from multiple clients to the same HTTP transport layer.",
  "technicalDetails": "The vulnerability resides within the request-response correlation logic of the @modelcontextprotocol/server component. In stateless HTTP environments, the server maintains an internal association between incoming messages and the active connection context. However, the implementation fails to adequately scope these associations to unique client identities.\nThe protocol uses JSON-RPC request identifiers to track message flow. Because the SDK clients initialize these identifiers starting at zero, predictable collisions occur as soon as multiple clients begin interacting with the service. The server fails to implement a secondary, session-bound verification step to ensure the requester is the intended recipient of the specific message payload.\nThe attack flow follows a predictable sequence: 1) A developer deploys an MCP server instance configured for stateless HTTP transport. 2) Two distinct clients (Client A and Client B) establish connections to the same endpoint. 3) Client A and Client B initiate requests simultaneously, both sending requests with identical JSON-RPC identifiers (e.g., '0'). 4) The server processes these concurrent requests. 5) When the server generates a response or sends an asynchronous notification, the internal lookup mechanism maps the response to a message ID rather than a specific connection object. 6) The server inadvertently routes the message back to the first available connection matching that ID, causing Client B to receive a message intended for Client A.\nThis flaw effectively breaks the isolation boundary between independent MCP sessions. If the server application exposes sensitive tools or context to client sessions, an attacker could intercept data packets containing potentially confidential information from another user's session.\nThe issue is specific to the @modelcontextprotocol/server package. It does not affect stdio-based transport mechanisms, nor does it impact architectures that employ a factory pattern to instantiate a fresh server or transport object for every individual request or session. Because this is a architectural flaw in the transport handling logic, simple configuration changes are insufficient to remediate the vulnerability.\nUpgrading to version 2.3.0 or later alters the behavior of reused instances, which may result in application-level failures for configurations currently using a single shared instance, necessitating a redesign of the server's lifecycle management to adhere to per-session instantiation patterns."
}