MCP TypeScript SDK vulnerabilities

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.

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.

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.