MCP TypeScript SDK: a shared server instance mixed up clients' replies

01What happened

The MCP TypeScript SDK maintainers published GHSA-jm63-cq47-j5jp on October 15, 2026 as CVE-2026-111770, rated High at CVSS 7.7, and it reached the GitHub Advisory Database on October 20. DavidCarliez and legitu1337 are credited as reporters. Two further advisories for the same packages carry the same October 15 date, both about missing limits on request size and validation work.

02How it works

The SDK matched incoming messages to connections using the JSON-RPC id alone. SDK clients number their requests from 0, so ids collide routinely between clients, and a server that created one stateless transport or one McpServer or Server instance at startup could hand a reply to the wrong connection. The advisory classes the defect as a race condition, CWE-362, with a High confidentiality impact in its CVSS vector.

03Who is affected

Applications on @modelcontextprotocol/server 2.0.0 through 2.2.0 that create the transport or server once at startup are affected. The advisory states that stdio servers, createMcpHandler() used with a per-call factory, and @modelcontextprotocol/sdk 1.26.0 and later are not affected. A multi-tenant MCP server reached over Streamable HTTP is the exposed shape.

04What to do

Upgrade @modelcontextprotocol/server to 2.3.0. Where that must wait, create the transport and server per request instead of once at startup, or move to createMcpHandler() with a per-call factory. Treat the two other October 15 advisories in the same pass: both need a new option set rather than an upgrade alone, as the table below records.

Questions people ask

Is my MCP server affected if it runs over stdio?

Stdio servers are not affected, according to the advisory for CVE-2026-111770, because the flaw needs several HTTP clients sharing one transport or server instance. The advisory also exempts createMcpHandler() used with a per-call factory, and @modelcontextprotocol/sdk version 1.26.0 and later. Servers reached over Streamable HTTP that build the transport once at startup are the exposed configuration.

What data could leak between MCP clients?

Responses and notifications meant for one HTTP client could reach another, because the SDK matched messages to connections on the JSON-RPC id alone. Whatever a tool call returns is therefore exposed to a different caller, which on a multi-tenant MCP server can mean another tenant's tool output. The advisory rates confidentiality impact High within its CVSS 7.7 vector.

What else did the MCP TypeScript SDK fix on October 15?

Two further advisories carry the same date. CVE-2026-111768 covers unbounded validation of array elements and object keys, where one request inside the default 4 MiB limit could exhaust server memory. GHSA-f897-62hf-6gxq covers HTTP transports that capped neither request body size nor JSON-RPC batch length. Both are rated High, and both reach beyond the server package into sdk, node and hono.

Does upgrading alone close all three October 15 MCP SDK issues?

Upgrading closes CVE-2026-111770, but the two resource-limit advisories also need configuration. The maxToolInputElements option on McpServer is off by default in sdk 1.32.0 and server 2.3.0, and maxRequestBodySize arrived in sdk 1.30.1 and server 2.1.0. Patched versions do start returning HTTP 413 above 4 MiB and HTTP 400 for batches over 100 messages.

Sources 3 links, all fetched

1. 1github.comGHSA-jm63-cq47-j5jp
2. 2github.comMemory Exhaustion CVE
3. 3github.comRequest Limit Advisory