CVE-2026-111769: Model Context Protocol TypeScript SDK: HTTP client transports and OAuth requests followed cross-origin redirects and re-sent custom headers and request bodies
Summary In affected versions, the SDK's HTTP client transports and OAuth requests followed redirects to any origin.
If an MCP server or authorization server redirected a request to another origin, that origin received custom request headers (such as an X-API-Key set in requestInit.headers) and the mcp-session-id header. On a 307 or 308 it also received the request body, including OAuth token requests with their refreshtoken and clientsecret.
On current runtimes fetch already drops the Authorization header across origins.
Am I affected? Yes, if your application uses StreamableHTTPClientTransport, SSEClientTransport, or the SDK's OAuth client functions such as auth(). stdio clients are not affected.
Affected versions:
- @modelcontextprotocol/sdk all versions through 1.31.0 - @modelcontextprotocol/client 2.0.0 through 2.2.0
Fix Upgrade to:
- 1.x: @modelcontextprotocol/sdk 1.32.0 or later - 2.x: @modelcontextprotocol/client 2.3.0 or later
Redirects are now followed only within the same origin, and not at all in browsers. If your MCP server or authorization server redirects to another origin on purpose, configure the final URL instead. Setting redirectPolicy: 'follow' on a transport restores the old behaviour and the exposure.
If a redirect may have reached a host you do not control, rotate the API keys and clientsecret your application held and revoke its tokens.
If you cannot upgrade yet, pass a fetch that refuses redirects, for example (url, init) => fetch(url, { ...init, redirect: 'error' }).
Other sources
The Model Context Protocol TypeScript SDK provides TypeScript client and server implementations of the Model Context Protocol. Prior to 1.32.0 in @modelcontextprotocol/sdk and from 2.0.0 until 2.3.0 in @modelcontextprotocol/client, the HTTP client transports and OAuth client requests followed redirects to a different origin while retaining custom request headers and, for HTTP 307 or 308 responses, request bodies. The affected surfaces are StreamableHTTPClientTransport, SSEClientTransport, and OAuth client functions such as auth(). The trigger is an HTTP redirect to another origin. Custom headers and mcp-session-id can be re-sent to the redirected origin. HTTP 307 and 308 redirects can also re-send the request body. OAuth request bodies can contain refreshtoken and clientsecret values. Current runtimes already strip the Authorization header across origins. stdio clients do not use the affected HTTP path. A malicious or compromised MCP or authorization server could therefore receive API keys, session identifiers, OAuth refresh tokens, or OAuth client secrets. Restoring unrestricted redirect following after upgrading restores the exposure. This issue is fixed in @modelcontextprotocol/sdk 1.32.0 and @modelcontextprotocol/client 2.3.0.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/@modelcontextprotocol/clientto a version that resolves this vulnerability.Fixed in 2.3.0 - Upgrade
Upgrade
npm/@modelcontextprotocol/sdkto a version that resolves this vulnerability.Fixed in 1.32.0 - Upgrade
Upgrade
@modelcontextprotocol/sdkto a version that resolves this vulnerability.Fixed in 1.32.0 - Upgrade
Upgrade
@modelcontextprotocol/clientto a version that resolves this vulnerability.Fixed in 2.3.0 - Configuration
If you cannot upgrade yet, pass a fetch implementation that sets redirect: 'error' to refuse redirects.
MCP HTTP client transports and OAuth client requests fetch redirect = error - Configuration
If the server intentionally redirects to another origin, configure the final URL directly instead of redirecting.
MCP server or authorization server redirect destination = final URL - Operational
If a redirect may have reached a host you do not control, rotate the API keys and client_secret held by the application and revoke its tokens.
Event History
Frequently Asked Questions
Which client integrations are not affected?
stdio clients are not affected. The exposure applies to applications using StreamableHTTPClientTransport, SSEClientTransport, or the SDK OAuth client functions such as auth().
What data can be exposed when a cross-origin redirect occurs?
The redirected origin can receive custom request headers, including an X-API-Key supplied in requestInit.headers, and the mcp-session-id header. For 307 or 308 redirects, it can also receive the request body, including OAuth token requests containing refresh_token and client_secret values.
Does the runtime's handling of the Authorization header prevent this issue?
No. Current runtimes already drop the Authorization header across origins, but custom headers and the mcp-session-id header could still be sent to the redirected origin.
What can be done if an MCP or authorization server intentionally redirects to a different origin?
Configure the final URL directly rather than relying on the cross-origin redirect. Fixed versions only follow redirects within the same origin, and do not follow redirects in browsers.
Which package versions need upgrading?
Upgrade @modelcontextprotocol/sdk 1.x to 1.32.0 or later, or @modelcontextprotocol/client 2.x to 2.3.0 or later. Affected ranges are SDK versions through 1.31.0 and client versions 2.0.0 through 2.2.0.