CVE-2026-104850
HighCVSS 7.5Summary
MCP TypeScript SDK versions from 1.12.0 before 1.31.0 and 2.2.0 let the MCP server a client connects to decide which authorization server receives 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 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 applications using 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 do 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 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 trusted MCP servers.
Risk Assessment
Exposure of OAuth credentials (refresh tokens, client secrets) to a malicious server may lead to unauthorized access to protected resources and account security breaches.
Recommendation
Upgrade @modelcontextprotocol/sdk to version 1.31.0 (for 1.x) or @modelcontextprotocol/client to version 2.2.0 (for 2.x). If unable to upgrade, connect OAuth-enabled clients only to trusted MCP servers.
Other vulnerabilities in MCP TypeScript SDK
See all- CVE-2026-25536High
A vulnerability in the MCP TypeScript SDK allows cross-client response data leak when a single server and transport instance is reused across multiple client connections. The issue affects versions 1.10.0 through 1.25.3, most notably in stateless StreamableHTTPServerTransport deployments.
- CVE-2026-0621High
A ReDoS vulnerability in Anthropic's MCP TypeScript SDK up to version 1.25.1 exists in the UriTemplate class when processing RFC 6570 exploded array patterns. The dynamically generated regular expression contains nested quantifiers that can cause catastrophic backtracking on specially crafted inputs, leading to excessive CPU consumption.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS