← News
/DISPATCH · 2026-09-30

MCP Python SDK High-Severity OAuth Flaw Puts AI Agent Accounts at Risk

The MCP Python SDK versions 1.9.1 through 1.29.1 and 2.0.0 through 2.1.1 contain an OAuth trust flaw that can allow a malicious MCP server to take over AI Agent accounts. Developers should upgrade to 1.30.0 on the 1.x branch or 2.2.0 on the 2.x branch.

The official MCP Python SDK contains a high-severity OAuth authentication flaw. If an AI Agent or its client connects to a malicious MCP server, an attacker may obtain OAuth authentication material and take over the associated user or agent account.

Affected versions are MCP Python SDK 1.9.1 through 1.29.1 on the 1.x branch and 2.0.0 through 2.1.1 on the 2.x branch. Maintainers recommend upgrading to 1.30.0 on 1.x or 2.2.0 on 2.x.

OAuth trust in the MCP protocol

MCP is an open protocol used to connect AI assistants and agents to external tools, APIs, and data sources. In production, agents often complete OAuth so they can call protected resources such as email, calendars, and enterprise systems.

Clients built on the MCP Python SDK could over-trust OAuth service-discovery data returned by an MCP server. That trust allowed a hostile server to alter OAuth configuration and send authentication material to attacker-controlled infrastructure.

Impact on tokens and accounts

The SDK did not strictly validate OAuth configuration supplied by the MCP server. It did not adequately verify that the issuer value matched the expected identity provider.

A user may be shown a genuine login page for Google, Okta, or Microsoft Entra ID while later stages of the flow are redirected. Valid access tokens can then be obtained from the real identity provider.

After a successful attack, exposed material may include authorization codes, client secrets, and PKCE code verifiers. PKCE is meant to stop token exchange when only an authorization code is stolen. If those values are all exposed to an untrusted server, PKCE does not contain the impact.

Affected OAuth providers

The issue is not limited to a single provider class. The following are in scope:

Interactive OAuth providers are rated 6.5 because a user still takes part in login. Machine-to-machine providers are rated 7.5 because no user interaction is required and the activity can be more covert.

AI Agent environments

Risk is higher where a model can select MCP servers and the system lacks strict server checks and permission boundaries. If an agent reaches an untrusted server, an attacker may retain valid tokens and access resources that the user or enterprise already authorized. Long-lived tokens increase the window for abuse of mail, calendars, and other connected systems.

Patches and follow-up

Fixed releases add stronger checks on the authorization server issuer and reject metadata from unexpected providers.

1. Upgrade the SDK. Move the 1.x branch to 1.30.0 and the 2.x branch to 2.2.0.

2. Set the expected issuer explicitly. Systems that use ClientCredentialsOAuthProvider or PrivateKeyJWTOAuthProvider should also set the issuer= parameter to the intended identity provider.

3. If the application connected to untrusted MCP servers before the fix, clear old OAuth registrations, rotate client secrets, revoke tokens that may have been exposed, and review access logs for unusual activity.

Enterprises should inventory which MCP servers agents may contact, which OAuth providers are trusted, and which actions touch high-privilege data. Allowlists, least privilege, issuer validation, and anomaly detection on token use belong in the same control set.

Reporting is based on Cybersecurity News coverage and Cycode technical disclosure and security advisories.