Anthropic MCP Python SDK Flaw Enables OAuth Credential Theft and Account Takeover

Security researchers have disclosed a high-severity vulnerability in Anthropic’s Model Context Protocol (MCP) Python SDK. This flaw could allow a malicious MCP server to steal OAuth credentials, potentially taking over user accounts.

The vulnerability affects MCP client deployments that use HTTP transport and includes vulnerable SDK releases from versions 1.9.1 to 2.1.1.

Research from Cycode indicates that an attacker-controlled MCP server can exploit weaknesses in the SDK’s OAuth discovery process and redirect sensitive token-exchange data to an endpoint operated by the attacker.

The compromised data can include OAuth client secrets, authorization codes, and PKCE code_verifier values, information sufficient to obtain legitimate access tokens from the victim’s real identity provider.

Anthropic MCP Python SDK Flaw

MCP clients use OAuth discovery to identify where users should authenticate and where authorization codes should be exchanged for tokens. Typically, the SDK identifies an authorization server, retrieves its metadata, and validates that the issuer of this metadata matches the expected server identity.

The vulnerability occurs on a legacy fallback path. If a malicious MCP server returns an HTTP 404 when the SDK requests modern authorization-server discovery metadata, the client is forced to retrieve OAuth configuration directly from the MCP server, which can control the endpoint URLs returned.

On this fallback path, issuer validation only occurs when an authorization-server URL is already available. Since the fallback leaves this value unset, the check is skipped instead of failing.

This allows the malicious server to supply attacker-controlled token endpoints while falsely declaring the legitimate identity provider as its issuer.

The attack is particularly deceptive because the authentication page can appear legitimate. The malicious MCP server can direct users to the actual login pages of providers like Google, Okta, Azure AD, or other enterprise identity providers, enabling victims to authenticate normally.

However, after users approve authentication, the SDK sends the authorization code, client secret, and PKCE proof key to a token endpoint specified in the attacker-controlled metadata.

Although PKCE is intended to prevent intercepted authorization codes from being reused, this attack captures both the code and its verifier, circumventing that protection. The attacker can then exchange this information at the genuine authorization server to obtain a valid access token.

The risk is heightened by the possibility of long-lived client secrets and refresh tokens. An attacker could retain access until these secrets are rotated or tokens are explicitly revoked, potentially granting access to cloud resources, internal APIs, data stores, deployment pipelines, and other services associated with the affected OAuth client.

The issue impacts HTTP-based MCP clients using the following providers:

SDK branch	Vulnerable versions	Fixed version
1.x	1.9.1–1.29.1	1.30.0
2.x	2.0.0–2.1.1	2.2.0

Affected providers include OAuthClientProvider, ClientCredentialsOAuthProvider, and PrivateKeyJWTOAuthProvider. Machine-to-machine providers are particularly concerning, as they can operate without user interaction, exposing automated AI agents and backend workflows to silent credential theft. MCP servers built with the SDK, local stdio clients, and those supplying their own tokens or headers are not affected.

Organizations are urged to upgrade immediately to MCP Python SDK versions 1.30.0 or 2.2.0 or later. The patched versions validate the expected authorization server before accepting metadata and bind stored credentials to their authorized issuer.

Teams utilizing ClientCredentialsOAuthProvider or PrivateKeyJWTOAuthProvider should also explicitly set the `issuer=` parameter.

Additionally, they should clear legacy stored OAuth client registrations, rotate client secrets, and revoke issued tokens if any vulnerable client has connected to an untrusted MCP server. Until the patch is applied, the only reliable mitigation is to restrict connections to fully trusted MCP servers.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC