A serious vulnerability has been uncovered in the official Python SDK for MCP (Model Context Protocol) that allows malicious MCP servers to trick client applications into handing over OAuth credentials. This flaw affects versions before 1.30.0 in the 1.x line and before 2.2.0 in the 2.x line. Patch releases are available with fixes.
What MCP Is & How the Flaw Works
MCP is an open standard designed to connect AI apps with external services, tools, and data sources. Its official Python SDK supports both MCP servers and clients. The disclosed vulnerability allows a malicious server to misroute sensitive data—namely the OAuth client secret, authorization code, and PKCE proof key—to an attacker’s token endpoint instead of the legitimate one. With those, the attacker can obtain valid access tokens carrying whatever permissions the client holds. Since the client secret is long-lived, it remains valid until explicitly changed.
Who’s At Risk & Severity
Applications using the SDK as an MCP client via certain OAuth providers are vulnerable if they connect to a server they don’t fully trust. Affected providers include OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider, and the deprecated RFC7523OAuthClientProvider line. Unsafe behavior happens when clients rely on untrusted servers to supply the identity of the real authorization server. Machine-to-machine providers are fully exposed since no human interaction is needed; the interactive provider requires user consent but users will see the genuine login UI, making the attack stealthy.
Fixes & Mitigations
Upgrading to SDK version 1.30.0 (for 1.x) or 2.2.0 (for 2.x) closes the hole. In those versions, clients verify which authorization server they expect before trusting any server-provided login service details. However, for configurations using ClientCredentialsOAuthProvider or PrivateKeyJWTOAuthProvider, an additional parameter must be set: issuer=
After You Upgrade
Once updated, clients should clear stored OAuth registrations created under older, vulnerable SDK versions since prior registrations may still allow credential misuse. If there’s chance a client connected to a malicious server previously, client secrets should be rotated, and any affected tokens revoked. In older SDKs, there’s no patch-like workaround unless only connecting to MCP servers fully under one’s control.
Timeline & Disclosure
The issuer bound checks were added in the SDK releases on September 7, with the advisory following on September 28. The vulnerability was reported by Cycode, which also carried out a proof-of-concept showing credential theft and token misuse. No evidence so far indicates the flaw has been exploited in the wild.
Moving forward, this vulnerability highlights the fragile nature of delegation/authentication systems—especially in protocols facilitating AI‐agent or tool integrations like MCP. It shows how critical it is to enforce trust boundaries, validate server origins, and avoid reliance on data from untrusted sources. For anyone building AI integrations, this serves as a warning: always require specific issuer configuration and maintain strict version discipline. Watch how widely affected this may be in real deployments, and whether tooling support emerges to audit configurations automatically.
