MCP TypeScript SDK CVE-2026-111769

The application must use @modelcontextprotocol/sdk (<1.32.0) or @modelcontextprotocol/client (2.0.0-2.2.0) via StreamableHTTPClientTransport, SSEClientTransport, or OAuth client functions such as auth(); stdio clients are explicitly not affected. Actual exposure requires the connected MCP server or authorization server to issue a cross-origin redirect toward an origin the attacker controls or can observe - i.e. a malicious/compromised server endpoint or a network MITM position - so a client talking only to a trusted first-party server over TLS is not practically exploitable. Header leakage (X-API-Key, mcp-session-id) occurs on any followed redirect, but body/secret leakage (refresh_token, client_secret) requires a method-preserving 307 or 308 redirect. Limiting factors: modern fetch already drops the Authorization header across origins; browser runtimes never expose redirect targets so the request simply fails there; and in fixed versions the vulnerable behavior only returns if an operator explicitly sets redirectPolicy: 'follow'.

This is a moderate-severity information-disclosure flaw (CWE-200) in the Model Context Protocol TypeScript client SDK, where HTTP transports and OAuth helpers followed redirects to any origin, leaking custom headers (e.g. X-API-Key), the mcp-session-id, and - on 307/308 - the request body including OAuth refresh_token and client_secret. The vendor CVSS vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N = 6.5) is internally consistent and credible: network vector and no client-side authentication (PR:N), but high attack complexity (AC:H) because exploitation is not self-contained - it requires the MCP server or authorization server the client connects to issue a cross-origin redirect toward an attacker-observable origin, meaning the attacker must control/compromise that server endpoint or hold a network MITM position. No EPSS score, KEV listing, POC, or SSVC decision data was supplied, so exploitation probability cannot be quantified from the input: no public exploit identified at time of analysis. The realistic priority is elevated for organizations building MCP clients that connect to third-party or untrusted MCP/authorization servers (credential and token theft is directly enabled), but lower for clients that only talk to fully-trusted first-party servers over TLS. This is a genuine credential-exposure bug rather than a high-CVSS-but-hollow issue, yet its real-world urgency is tempered by the AC:H precondition and the mitigating fact that modern fetch already strips the Authorization header cross-origin.

An application using StreamableHTTPClientTransport, SSEClientTransport, or the SDK's OAuth auth() helpers connects to a malicious or compromised MCP/authorization server (or an attacker performs a MITM on the connection). The server responds with a 307/308 redirect to an attacker-controlled origin, and the vulnerable client automatically re-sends its custom headers and request body - handing over X-API-Key, mcp-session-id, and OAuth refresh_token/client_secret. No public exploit code was identified in the provided data, but the technique is straightforward once an attacker controls a redirect target.