High-Severity Vulnerability Discovered in Anthropic’s MCP Python SDK
Security researchers have revealed a significant vulnerability within the Model Context Protocol (MCP) Python SDK developed by Anthropic. This flaw poses alarming risks, as it could allow a malicious MCP server to compromise OAuth credentials, leading to the potential takeover of user accounts. The identification of this vulnerability underscores a critical need for immediate attention from organizations utilizing the affected SDK versions.
The vulnerability specifically impacts MCP client deployments that utilize HTTP transport. It encompasses several vulnerable SDK releases, notably from versions 1.9.1 to 2.1.1. The implications of this flaw are significant, as it affects a wide array of services relying on OAuth authentication processes.
According to research conducted by Cycode, the underlying issue lies in how the SDK handles its OAuth discovery process. An attacker-controlled MCP server can exploit vulnerabilities within this process, redirecting critical token-exchange data to an endpoint that they control. Such compromised information can include OAuth client secrets, authorization codes, and PKCE code_verifier values, all of which are essential for acquiring legitimate access tokens from the victim’s actual identity provider.
MCP clients utilize OAuth discovery to determine the appropriate places for user authentication and the processes involved in exchanging authorization codes for tokens. Generally, the SDK identifies an authorization server, retrieves its metadata, and validates that the issuer of this metadata corresponds with the expected server identity. However, the vulnerability manifests through a legacy fallback path. If a malicious MCP server returns an HTTP 404 error when the SDK requests modern authorization-server discovery metadata, the client is compelled to obtain OAuth configuration directly from the MCP server. This situation allows the malicious server to manipulate the endpoint URLs returned to the SDK.
In this fallback situation, issuer validation only occurs if an authorization-server URL is already in place. Thus, when this value is not set, the validation check is bypassed without failing, leading to a security breach. Consequently, the malicious server is given the opportunity to furnish attacker-controlled token endpoints, misleadingly declaring the legitimate identity provider as its issuer.
What exacerbates this vulnerability is its deceptive nature. The authentication pages displayed to users can appear entirely legitimate, as the malicious MCP server can redirect users to the actual login pages of reputable providers like Google, Okta, or Azure AD. This illusion of authenticity permits users to authenticate without suspicion. However, after authenticating, the SDK inadvertently sends the authorization code, client secret, and PKCE proof key to a token endpoint delineated in the attacker’s metadata.
Despite the intention of PKCE to thwart the reuse of intercepted authorization codes, this attack effectively circumvents that protection by capturing both the authorization code and its verifier. The attacker thus can exchange this captured data with the genuine authorization server, retrieving a valid access token.
The ramifications of this vulnerability are particularly concerning due to the possibility of long-lived client secrets and refresh tokens. An attacker could maintain access until these secrets are rotated or the tokens are revoked, potentially granting them access to vital cloud resources, internal APIs, data repositories, and deployment pipelines associated with the affected OAuth client.
This issue impacts various HTTP-based MCP clients, including those utilizing the OAuthClientProvider, ClientCredentialsOAuthProvider, and PrivateKeyJWTOAuthProvider. The threat is notably pronounced for machine-to-machine providers, which can function without user interaction, exposing automated AI agents and backend workflows to silent credential theft. Importantly, MCP servers constructed using the SDK, along with local stdio clients or those that supply their own tokens or headers, remain unaffected.
Organizations are urgently advised to upgrade their systems to MCP Python SDK versions 1.30.0 or 2.2.0 or subsequent releases. The updated versions enforce strict validation of the expected authorization server before accepting metadata, addressing the vulnerability by binding stored credentials to their authorized issuer.
Furthermore, teams leveraging ClientCredentialsOAuthProvider or PrivateKeyJWTOAuthProvider should explicitly configure the issuer= parameter. It is also essential for them to clear any previously stored OAuth client registrations, rotate existing client secrets, and revoke any issued tokens if any vulnerable client has connected to an untrusted MCP server. Until the necessary patches are applied, the most reliable way to protect against this vulnerability is to restrict connections solely to trusted MCP servers.
The discovery of this vulnerability highlights the need for heightened vigilance among organizations utilizing the MCP Python SDK. Immediate actions are necessary to safeguard sensitive credentials and mitigate potential risks associated with unauthorized account access.