Critical MCP Python SDK flaw exposes OAuth credentials to malicious servers

A critical security vulnerability in the official Model Context Protocol (MCP) Python SDK allows malicious MCP servers to steal OAuth credentials from connecting clients. The flaw, disclosed on September 28, 2026, affects versions 1.9.1 through 1.29.1 and 2.0.0 through 2.1.1, enabling attackers to intercept client secrets, authorization codes, and PKCE proof keys.

What happened

The maintainers of the MCP Python SDK issued a security advisory after researchers at Cycode demonstrated how a malicious server could trick an application into handing over sensitive authentication data. When an MCP client attempts to log in, it asks the connected server for the location of its authorization server. In the affected versions, the SDK did not strictly validate this response.

A malicious server could direct the client to an attacker-controlled endpoint or provide login details that appeared legitimate but routed credentials elsewhere. Consequently, the client would send its long-lived client secret, one-time authorization code, and PKCE proof key to the attacker. With these credentials, the attacker could request a valid access token from the real login service, gaining whatever permissions the original application held.

The severity of the flaw depends on the OAuth provider used. For machine-to-machine providers that operate without human intervention, the risk is rated high at 7.5. For interactive providers requiring user sign-in, the score is 6.5, though the user still approves the sign-in on a genuine-looking page. No CVE had been assigned as of September 29, 2026, and no active exploits have been reported in the wild.

How it works

The core issue lies in how the SDK handles the discovery of the authorization server. During the OAuth flow, the client relies on the MCP server to specify where to send authentication requests. The vulnerable SDK versions failed to verify if the specified authorization server matched the expected issuer before sending credentials.

This lack of validation allowed a malicious server to redirect the credential exchange. Even with PKCE (Proof Key for Code Exchange), which is designed to prevent authorization code reuse, the protection was nullified because the client voluntarily handed over the proof key to the attacker. This enabled the attacker to complete the token exchange process as if they were the legitimate client.

Key details

• Affected versions: MCP Python SDK 1.9.1–1.29.1 and 2.0.0–2.1.1.
• Fixed versions: Upgrade to 1.30.0 for the 1.x line or 2.2.0 for the 2.x line.
• Vulnerable providers: OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider, and the deprecated RFC7523OAuthClientProvider.
• Unaffected setups: MCP servers built with the SDK, local stdio clients, and clients that attach their own tokens are not vulnerable.
• Configuration requirement: For ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider, upgrading alone is insufficient; developers must also pass the issuer= parameter to lock the client to a specific login service.
• Post-upgrade action: Clear stored OAuth client registrations after upgrading, as older registrations are not tied to a specific login service.

Why it matters

For engineers building AI agents or integrating external tools via MCP, this vulnerability represents a significant trust boundary failure. The MCP standard is designed to connect AI applications to diverse data sources and tools, often involving third-party servers. If your application acts as an MCP client connecting to untrusted or semi-trusted servers, it risks exposing long-lived credentials that can grant persistent access to your services.

The subtlety of the fix adds operational complexity. Simply upgrading the SDK does not fully secure applications using certain OAuth providers unless the issuer parameter is explicitly configured. Since Python hides deprecation warnings by default, many developers might miss the critical instruction to add this parameter, leaving their applications vulnerable even after updating. This highlights the need for careful review of authentication configurations when adopting new standards like MCP.

What you can do

• Immediately upgrade to MCP Python SDK version 1.30.0 or 2.2.0.
• If using ClientCredentialsOAuthProvider or PrivateKeyJWTOAuthProvider, ensure the issuer= parameter is set to your expected login service.
• Migrate away from the deprecated RFC7523OAuthClientProvider, as it lacks the issuer= option entirely.
• Clear all stored OAuth client registrations once after upgrading to remove unbound entries.
• Rotate client secrets and revoke existing tokens at your login service if there is any chance your client connected to an untrusted server.
• Enable Python deprecation warnings in your development and staging environments to catch configuration issues early.