Description

MCP TypeScript SDK is the official TypeScript SDK for Model Context Protocol servers and clients. Starting in version 1.12.0 and prior to versions 1.31.0 and 2.2.0, the SDK's OAuth client support let the MCP server a client connected to decide which authorization server received the client's OAuth credentials. Stored and pre-provisioned credentials were not bound to the authorization server they belong to. A malicious or compromised MCP server could name its own authorization server in its protected resource metadata. Without any user interaction, the client would send that server the `refresh_token` and `client_secret` stored from an earlier sign-in (1.x), or the configured `client_secret` or signed assertion of a bundled non-interactive provider (1.x and 2.x). Only those applications that use the SDK as an MCP client over HTTP with an `authProvider`: your own `OAuthClientProvider`, or the bundled `ClientCredentialsProvider`, `PrivateKeyJwtProvider`, `StaticPrivateKeyJwtProvider` or (2.x) `CrossAppAccessProvider` and that may connect to an MCP server the owners does not fully trust while holding credentials for a legitimate authorization server are affected. `@modelcontextprotocol/sdk` 1.31.0 (1.x) and `@modelcontextprotocol/client` 2.2.0 (2.x) patch the issue. A workaround for those who cannot upgrade is available. 2.0.0 and 2.1.0 already accept `expectedIssuer`. On 1.x, the only workaround is to connect OAuth-enabled clients only to MCP servers you trust.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-10-06T17:17:15.827Z",
  "pubdate": "2026-10-06T17:17:15.827Z",
  "executiveSummary": "The MCP TypeScript SDK is susceptible to an authentication credential leakage vulnerability stemming from improper validation of authorization server endpoints.\nThis vulnerability allows a malicious or compromised MCP server to intercept sensitive OAuth credentials, including refresh tokens and client secrets, by misleading the MCP client into sending them to an attacker-controlled authorization server.\nThe flaw affects applications utilizing the SDK as an MCP client over HTTP, specifically when using providers such as OAuthClientProvider, ClientCredentialsProvider, PrivateKeyJwtProvider, StaticPrivateKeyJwtProvider, or CrossAppAccessProvider.\nSuccessful exploitation allows an attacker to exfiltrate valid credentials without user interaction, potentially granting unauthorized access to legitimate third-party services.\nThe risk is significant for clients configured to trust arbitrary or untrusted MCP servers. Exploitation is contingent upon the client connecting to a malicious server while holding credentials intended for a legitimate authorization provider.\nRemediation requires upgrading to version 1.31.0 (for the 1.x branch) or 2.2.0 (for the 2.x branch). For users unable to update, strict isolation of OAuth-enabled clients to only trusted server endpoints is required.",
  "technicalDetails": "The root cause of this vulnerability is a failure in the MCP TypeScript SDK to enforce an association between stored OAuth credentials and the specific, intended authorization server. The SDK permits the connected MCP server to designate the authorization server endpoint via its protected resource metadata.\nBecause the SDK does not bind pre-provisioned credentials—such as refresh tokens and client secrets—to the metadata of the originating authorization server, a malicious MCP server can inject its own URI into the configuration. When an MCP client attempts an authentication flow or refresh operation, the SDK blindly transmits the credentials associated with the legitimate service to the attacker's endpoint.\nAffected components include the OAuth client support logic within the @modelcontextprotocol/sdk. Specifically, the vulnerability resides in how the SDK processes authorization server discovery metadata provided by the MCP server.\nThe attack flow follows these steps: 1) A victim client connects to a malicious MCP server. 2) The server returns protected resource metadata containing a fraudulent authorization server URL. 3) The client, relying on its internal configuration of OAuth providers (e.g., ClientCredentialsProvider or PrivateKeyJwtProvider), attempts to authenticate or refresh its token. 4) The SDK, failing to validate that the target issuer matches the expected legitimate issuer, sends the stored `refresh_token`, `client_secret`, or signed assertions to the attacker-controlled server. 5) The attacker captures these credentials and can subsequently impersonate the client against the actual authorization server.\nThis exploit does not require user interaction, as the SDK performs these operations programmatically based on the server's instructions. The vulnerability is present in versions starting from 1.12.0 up to, but not including, 1.31.0 and 2.2.0.\nFor versions 2.0.0 and 2.1.0, the SDK already supports the `expectedIssuer` configuration, which serves as a security boundary to prevent this redirection. However, the absence of this enforcement in older versions and the permissive nature of the protocol handling enable the unauthorized credential exfiltration."
}