An MCP server that authenticates its users can still misdeliver their data when the response router fails to preserve connection identity. The October 15 maintainer advisory describes affected applications that instantiate one HTTP transport or McpServer at process startup and reuse it for independent clients. Because ordinary SDK clients generate JSON-RPC…
Case · DiggingBeagle record
Shared MCP TypeScript HTTP server instances leak messages across clients
The official MCP TypeScript SDK could route one HTTP client's tool responses to another when an application reused a server or transport instance and JSON-RPC request IDs collided.
Scope
HTTP MCP server deployments using shared application-level server or transport instances, not stdio or correctly separated request sessions.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade B
- Remediation
- patch available
- AI role
- AGAINST AI
Basis and provenance
Maintainer GHSA-jm63-cq47-j5jp documents cross-client response/notification routing under shared HTTP transport/server instances and lists version 2.3.0 as patched. A code-pattern prerequisite and post-upgrade application changes are explicit. No confirmed customer data spill or victim denominator is published.
Assessed Oct 17, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-MCP-TS-FIX-PATTERN · CLM-MCP-TS-CROSS-ROUTING · MCP TypeScript SDK GHSA-jm63-cq47-j5jp: shared transport leaks HTTP client messages
At a glance
Correct authentication does not establish isolation when routing binds messages to reusable identifiers instead of the originating client connection.
Read the implicationsNumber of exposed deployments, affected client data and any observed malicious exploitation were not established. Actual deployed applications and integration adapters must be inspected; an upgraded singleton application may fail requests.
Limits and uncertaintyFull account
An MCP server that authenticates its users can still misdeliver their data when the response router fails to preserve connection identity. The October 15 maintainer advisory describes affected applications that instantiate one HTTP transport or McpServer at process startup and reuse it for independent clients. Because ordinary SDK clients generate JSON-RPC IDs beginning at zero, distinct sessions can issue colliding identifiers. Routing by the identifier alone can send replies or notifications across the wrong boundary. This is an HTTP transport defect, not a model deciding to share data.
The advisory covers @modelcontextprotocol/server 2.0.0 through 2.2.0. In 2.3.0, attempts to reuse connected server instances fail rather than allowing misrouting, but applications retaining the old singleton pattern may stop serving second requests after the upgrade. Deployment remediation therefore requires constructing fresh server and transport objects per request, or separating them per authenticated session. A factory passed to createMcpHandler() is supported. stdio-only operation and properly isolated per-request servers are not in the described affected scope.
The affected legacy examples in Hono, Express, Fastify and Node.js matter because documentation may have spread the vulnerable pattern into downstream applications. The scope of actual exposure and malicious exploitation remains unknown.
Timeline
- Oct 15, 2026disclosure
Public disclosure
Claims & evidence
CLM-MCP-TS-FIX-PATTERNVersion 2.3.0 prevents reuse and requires applications to create new per-request or per-session server and transport instances, not simply update the package.supported
Basis: reported finding
- supportsMCP TypeScript SDK GHSA-jm63-cq47-j5jp: shared transport leaks HTTP client messagesprimary disclosure
Fix; affected versions; patched versions
CLM-MCP-TS-CROSS-ROUTINGMaintainers report that shared MCP server or transport instances could deliver another HTTP client's responses or notifications when JSON-RPC request identifiers collided.supported
Basis: reported finding
- supportsMCP TypeScript SDK GHSA-jm63-cq47-j5jp: shared transport leaks HTTP client messagesprimary disclosure
Summary; Am I affected?
Implications
Correct authentication does not establish isolation when routing binds messages to reusable identifiers instead of the originating client connection.
Controls and mitigations
- Update @modelcontextprotocol/server to 2.3.0 or newer and change singleton handlers to fresh instances per request or authenticated session.
- Test concurrent authenticated clients with colliding request IDs and verify response and notification recipient identities.
- Upgrade @modelcontextprotocol/server to 2.3.0 or later, then remove shared singleton server/transport instances: create them per request or independently per session.
- Verify that simultaneous client requests with overlapping JSON-RPC IDs never deliver either a response or a notification to the wrong client; merely upgrading can reject previously shared instances.
Unknowns and contradictions
- Number of exposed deployments, affected client data and any observed malicious exploitation were not established.
- Actual deployed applications and integration adapters must be inspected; an upgraded singleton application may fail requests.
Sources and citation
Material revision history
- Oct 17, 2026 · Published version · first publication · revision 163