Five MCP TypeScript SDK Flaws Let Clients Read Each Other's Messages and Tasks, and Two Fixes Need Config Changes

Five CVEs (CVE-2026-111767 to CVE-2026-111771) were added to the GitHub Advisory Database on 20 October 2026 for the Model Context Protocol TypeScript SDK. They cover a cross-client message leak, tasks that any session could touch, a one-request memory exhaustion, bearer tokens meant for other services, and cross-origin redirect following. The fixes ship in @modelcontextprotocol/sdk 1.32.0 and in the v2 packages at 2.3.0. Two of them, the memory and audience fixes, do nothing until you change configuration.

This is a separate set from CVE-2026-104850, the OAuth credential leak we covered earlier: MCP TypeScript SDK Lets a Malicious Server Pull OAuth Secrets From Clients.

The five CVEs

Cross-client message leak (CVE-2026-111770)

An MCP server reached over HTTP could return one client's responses and notifications to another when clients shared a single stateless transport, or one McpServer or Server instance. Messages were matched to a connection by JSON-RPC id alone, and SDK clients number requests from 0, so collisions happen in normal use. The README examples for the hono, express, fastify and node packages showed this pattern before 2.3.0.

Not affected: createMcpHandler() with a factory that builds a new server on every call, stdio servers, and @modelcontextprotocol/sdk 1.26.0 and later. After upgrading, shared instances fail: a second connect() rejects with ALREADY_CONNECTED and a stateless transport rejects its second request. Build a new McpServer and transport per request, or keep one per session with sessionIdGenerator set.

How a shared transport routes one client's response to another.

How a shared transport routes one client's response to another.

Tasks not tied to a session (CVE-2026-111767)

The experimental tasks feature did not check which session created a task. Clients sharing one InMemoryTaskStore could view, read and cancel other clients' tasks. You are exposed if an HTTP server passes taskStore to McpServer or Server. Upgrade to 1.32.0, remove taskStore, or create a separate store per session. The 2.x packages are not affected, and the advisory notes the experimental tasks are deprecated in favor of a redesigned extension in the 2026-07-28 specification.

Memory exhaustion (CVE-2026-111768)

Servers put no limit on the array elements and object keys validated in one request. A single request inside the default 4 MiB body limit could abort the process with "JavaScript heap out of memory". No credentials are needed unless you authenticate before the SDK. Risk is highest for tools whose inputs include arrays or records; stdio-only servers are not affected.

Upgrading alone does not prevent it. Set maxToolInputElements on McpServer (off by default; for example 10,000) and lower maxRequestBodySize on the transport or createMcpHandler(). If you parse the body yourself with express.json() or Fastify, set that limit instead. The body limit option needs sdk 1.30.1 or server 2.1.0; on older versions use a reverse proxy.

Wrong-audience tokens (CVE-2026-111771)

Server bearer authentication could not verify a token's audience. If one authorization server issues tokens for several services, a valid token meant for another service was accepted by the MCP server. You are affected if you use requireBearerAuth() or verifyBearerToken(), your authorization server serves other services, and your verifyAccessToken() does not check aud.

Fixed in sdk 1.32.0, server 2.3.0, express 2.0.2 and server-legacy 2.3.1, but the check is off by default. Pass your server's audience as a URL in expectedResource and return the token's audience from verifyAccessToken() as AuthInfo.resource. Doing only the first makes every request return 401. Without upgrading, reject tokens in verifyAccessToken() whose audience does not include your server.

Cross-origin redirects (CVE-2026-111769)

StreamableHTTPClientTransport, SSEClientTransport and the OAuth functions such as auth() followed redirects to any origin. A redirect target could receive custom headers (an API key in requestInit.headers) and mcp-session-id; on 307 and 308 the body went too, which could include a refresh token and client secret from an OAuth token request. Current runtimes already strip Authorization across origins. A compromised or misconfigured MCP or authorization server could capture the data.

The fix follows redirects only within the same origin, and not at all in browsers. redirectPolicy: 'follow' restores the old behaviour. Without upgrading, pass a fetch that uses redirect: 'error'.

What to do

1. Upgrade to @modelcontextprotocol/sdk 1.32.0 or the v2 packages at 2.3.0 (express 2.0.2, server-legacy 2.3.1).
2. Search for transports or servers created once at startup and shared across clients; restructure them.
3. Enable maxToolInputElements and a body size limit.
4. Set expectedResource and return AuthInfo.resource.
5. If a client may have been redirected to a host you do not control, rotate API keys and client secrets and revoke tokens.
6. Check for taskStore use on HTTP servers.

Sources

• https://github.com/advisories/GHSA-22jm-h49p-29qw
• https://github.com/advisories/GHSA-46jr-4wx8-v453
• https://github.com/advisories/GHSA-6prh-2h8m-c8cw
• https://github.com/advisories/GHSA-jm63-cq47-j5jp
• https://github.com/advisories/GHSA-rvq5-wwqv-78pq