Official MCP Python SDK Flaw Exposes OAuth Credentials to Malicious Servers
A critical vulnerability in the official MCP Python SDK (versions prior to 1.30.0 and 2.2.0) allows malicious servers to intercept and steal sensitive OAuth credentials, enabling session hijacking.
The official Python SDK for the Model Context Protocol (MCP), a standard for connecting AI applications to external tools and data, contains a critical flaw that could allow malicious servers to steal OAuth credentials. Versions of the SDK prior to 1.30.0 for the 1.x line and 2.2.0 for the 2.x line are affected, potentially exposing sensitive data such as client secrets, authorization codes, and PKCE proof keys.
This vulnerability, reported by security firm Cycode, allows an attacker-controlled server to trick an MCP client application into sending its OAuth credentials to a malicious token endpoint instead of the legitimate one. The SDK's maintainers acknowledged the flaw, noting that the affected versions did not always properly validate the authorization server's address. A malicious server could exploit this by either providing its own server's address or by serving login details that point to the user's real service while redirecting the actual credential submission to an attacker-controlled endpoint.
Once an attacker obtains these credentials, they can request a valid access token from the legitimate login service. This token would carry the same permissions as if the legitimate application had acquired it, granting the attacker access to protected resources. The client secret, being long-lived, remains a persistent threat until it is manually changed. The flaw has been rated high, with a CVSS score of 7.5 for machine-to-machine providers and 6.5 for interactive providers where user approval is still required.
The mechanism of the attack involves the MCP client querying the server for its authorization server's location. In vulnerable versions, the SDK fails to adequately verify this information. Consequently, a compromised server can redirect the client to an attacker-controlled endpoint. This redirection is particularly dangerous because the client then transmits its secret, authorization code, and the crucial PKCE proof key—a component designed to prevent the reuse of stolen authorization codes—directly to the adversary.
For interactive sign-ins, the user is presented with a genuine-looking login page, making the attack difficult to detect. However, for machine-to-machine authentication providers like ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider, the attack requires no user interaction. These providers are particularly vulnerable as they operate without human oversight, making them prime targets for automated credential theft.
Applications using the MCP Python SDK as an MCP client over HTTP with specific OAuth providers (OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider, and the deprecated RFC7523OAuthClientProvider) are at risk if they can connect to servers they do not fully control while holding credentials for a real login service. Local clients using stdio, MCP servers built with the SDK, and clients that manage their own tokens are not affected.
To mitigate this risk, users must upgrade to MCP Python SDK version 1.30.0 (for the 1.x branch) or 2.2.0 (for the 2.x branch). For ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider, simply upgrading is insufficient; users must also explicitly pass the issuer= parameter to specify the correct login service. After upgrading, it is recommended to clear stored OAuth client registrations and, if an untrusted server may have been accessed, rotate client secrets and revoke tokens at the login service. For older versions, the only workaround is to ensure connections are made exclusively to trusted MCP servers.
While the issuer checks were initially listed as behavior changes in the release notes for versions 1.30.0 and 2.2.0 on September 7, the official security advisory was published on September 28, coinciding with Cycode's detailed write-up. As of the advisory's release, no instances of exploitation in the wild had been reported.