Description

The Model Context Protocol TypeScript SDK provides TypeScript client and server implementations of the Model Context Protocol. From 1.6.0 until 1.32.0 in @modelcontextprotocol/sdk, from 2.0.0 until 2.3.0 in @modelcontextprotocol/server, from 2.0.0 until 2.0.2 in @modelcontextprotocol/express, and from 2.0.0 until 2.3.1 in @modelcontextprotocol/server-legacy, server-side bearer authentication could accept a valid access token issued for a different service because the SDK did not enforce the token audience. The affected surface is server-side HTTP bearer authentication. The trigger is a valid token whose audience names another service. The authorization server must issue tokens for multiple services, and the application's verifyAccessToken() must not independently validate aud. Applications already validating aud inside verifyAccessToken() are not affected. An attacker with a token for another service could authenticate to the MCP server and obtain the confidentiality and integrity capabilities granted to an authenticated caller. Upgrading alone leaves the new audience validation disabled. Operators must enable audience validation and provide the token audience together. Enabling only the expected audience check causes every request to receive HTTP 401. This issue is fixed in @modelcontextprotocol/sdk 1.32.0, @modelcontextprotocol/server 2.3.0, @modelcontextprotocol/express 2.0.2, and @modelcontextprotocol/server-legacy 2.3.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.8",
  "pubDate": "2026-11-05T21:18:35.973Z",
  "pubdate": "2026-11-05T21:18:35.973Z",
  "executiveSummary": "A critical security vulnerability exists in the Model Context Protocol (MCP) TypeScript SDK where server-side bearer authentication fails to enforce the 'aud' (audience) claim in JWT tokens.\nThis flaw allows an attacker to reuse a valid access token issued for a different service to authenticate against an MCP server, effectively bypassing intended authorization boundaries.\nAffected products include @modelcontextprotocol/sdk (1.6.0 - 1.31.x), @modelcontextprotocol/server (2.0.0 - 2.2.x), @modelcontextprotocol/express (2.0.0 - 2.0.1), and @modelcontextprotocol/server-legacy (2.0.0 - 2.3.0).\nThe risk implication is unauthorized access to the MCP server's resources, leading to potential breaches of confidentiality and integrity.\nSuccessful exploitation requires the attacker to possess a valid token from the same authorization provider intended for a different service and the target application must rely on the SDK's default implementation without secondary audience validation.\nUpgrading the SDK is a necessary but insufficient step, as operators must explicitly configure the expected audience to finalize the remediation.",
  "technicalDetails": "The root cause of this vulnerability is the absence of mandatory 'aud' (audience) claim validation within the bearer authentication logic of the MCP TypeScript SDK. JWT tokens often contain an 'aud' field to define the intended recipient of the token. By omitting a strict check against this field during token validation, the SDK treats any cryptographically valid token signed by a trusted provider as sufficient for authentication, regardless of the token's original target scope.\nThe vulnerable component is the authentication verification mechanism within the MCP server implementations. When an incoming HTTP request presents a bearer token, the verifyAccessToken() function performs signature verification but fails to compare the token's 'aud' claim against the expected identifier for the MCP server. Consequently, if an authorization server issues tokens for multiple services, an attacker in possession of a token scoped for 'Service A' can present that same token to 'Service B' (the MCP server), and the server will erroneously grant access.\nExploitation flow involves: 1) The attacker acquires a valid JWT issued by an identity provider for an arbitrary service they are authorized to access. 2) The attacker submits this token in the Authorization header of an HTTP request to the target MCP server. 3) The MCP server's verifyAccessToken() function succeeds because the signature is valid, and the missing 'aud' check allows the request to proceed. 4) The attacker is authenticated as a legitimate user, gaining all capabilities and permissions associated with the authenticated context of the MCP server, potentially leading to unauthorized data exfiltration or command execution depending on the server's capabilities.\nThe attack is limited to environments where the authorization server utilizes a shared trust model for multiple services and the MCP server does not implement additional custom validation logic to verify the audience independently. Even after applying the provided patches (e.g., @modelcontextprotocol/sdk 1.32.0), the vulnerability remains active if the operator does not explicitly configure and enable audience validation, as the SDK defaults to a permissive state to maintain backward compatibility during the transition period."
}