MCP Python SDK OAuth Flaw Lets Malicious Servers Hijack AI Agent Accounts

A high-severity flaw in the official Model Context Protocol (MCP) Python SDK could allow a malicious MCP server to steal OAuth authentication material and take over AI agent accounts.

The issue affects vulnerable HTTP-based MCP clients that connect to untrusted servers while using OAuth to access legitimate identity providers such as Google, Okta, or Microsoft Entra ID.

MCP is an open protocol that lets AI assistants and agents connect with external tools, APIs, and data sources. When an MCP client needs authentication, it performs OAuth discovery to determine which authorization server should handle login.

The vulnerable SDK trusted data supplied by the MCP server too heavily, allowing an attacker to redirect sensitive OAuth exchanges to attacker-controlled infrastructure.

MCP Python SDK OAuth Flaw

The attack begins when a malicious MCP server returns a 404 response to a modern authorization-server discovery request. This forces the SDK to use a legacy fallback path.

On that path, the SDK accepted OAuth configuration sent directly by the MCP server. However, it did not validate whether the declared OAuth issuer actually matched the expected login provider.

As a result, the attacker could provide a configuration that used the victim’s legitimate identity provider for the browser login page while pointing the OAuth token endpoint to a malicious server. The victim would see a normal sign-in page at the real Google, Okta, or Azure AD domain, making the flow appear legitimate.

After successful authentication, the affected SDK could send the authorization code, client secret, and PKCE code verifier to the attacker’s token endpoint. PKCE, or Proof Key for Code Exchange, is intended to stop attackers from using a stolen authorization code.

However, because the malicious server received both the authorization code and the PKCE verifier, it could complete the exchange with the real identity provider and obtain a valid access token for the victim’s account.

According to Cycode, the flaw also weakened credential-binding protections because the SDK validated stored credentials against an issuer value controlled by the malicious MCP server.

An attacker could impersonate the real authorization server, causing the SDK to reuse legitimate credentials and send them to an attacker-controlled endpoint.

Affected versions include MCP Python SDK 1.9.1 through 1.29.1 in the 1.x branch and versions 2.0.0 through 2.1.1 in the 2.x branch.

Impacted OAuth providers include OAuthClientProvider, ClientCredentialsOAuthProvider, and PrivateKeyJWTOAuthProvider. The deprecated RFC7523OAuthClientProvider may also be affected in older deployments.

The interactive OAuth provider was rated 6.5 because user interaction is required, though the genuine login page reduces this barrier, while machine-to-machine providers were rated High at 7.5 for requiring no user interaction.

AI agent environments face greater risk when models autonomously select MCP servers, as compromised registries, typosquatting, prompt injection, DNS hijacking, or network compromises can redirect agents to rogue servers.

Developers should upgrade to MCP Python SDK version 1.30.0 for the 1.x branch or version 2.2.0 for the 2.x branch. The patched releases validate the authorization-server issuer across discovery paths and reject metadata from an unexpected provider.

Organizations using ClientCredentialsOAuthProvider or PrivateKeyJWTOAuthProvider must also explicitly configure the expected issuer using the issuer= parameter.

They should clear older stored OAuth registrations, rotate exposed client secrets, and revoke tokens if an application may have connected to an untrusted MCP server before patching. MCP servers built with the SDK, local stdio clients, and clients that provide their own tokens or headers are not affected.

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