MCP Python SDK Flaw Exposes OAuth Credentials to Malicious Server

A security weakness in the official MCP Python software development kit can allow a malicious MCP server to capture the OAuth credentials an application uses to log in to an external service, the SDK's maintainers warned in a security advisory. The flaw, reported by the security firm Cycode, lets an untrusted server trick a client built with the affected versions into handing over its client secret, authorization code, and PKCE proof key. With those stolen secrets, an attacker can request a valid access token from the real login service and maintain persistent access until the credentials are changed.

The Model Context Protocol (MCP) is an open standard that lets artificial intelligence applications talk to outside tools and data sources, and the affected package is the official Python SDK for building MCP servers and clients. When an MCP client needs to log in, it asks the server where its authorization server (the service that handles logins and issues tokens) is located. On the vulnerable versions, the SDK trusted that answer without validation, so a hostile server could redirect the client to an attacker-controlled endpoint while showing the user the genuine login page. The client would then send its secret, authorization code, and PKCE proof key directly to the attacker, defeating the purpose of the proof key and exposing long-lived credentials.

The advisory rates the flaw as high severity (7.5 out of 10) for the two machine-to-machine OAuth providers that operate without any user interaction. The interactive provider, which requires a person to approve a sign-in, receives a score of 6.5 because the user still sees and approves what appears to be the legitimate login page. No CVE identifier had been assigned as of September 29. Affected versions span the 1.x line from 1.9.1 through 1.29.1 and the 2.x line from 2.0.0 through 2.1.1; the fixes are in versions 1.30.0 and 2.2.0. Applications are at risk only if they use the SDK as an MCP client over HTTP with one of the listed OAuth providers (OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider, or the deprecated 1.x RFC7523OAuthClientProvider), hold credentials for a real login service, and can connect to a server they do not fully control.

To close the vulnerability, users must upgrade to the patched release and, for the ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider, additionally pass an issuer= argument that names the expected authorization server. Without that argument, the client will still follow any endpoint the MCP server provides, even on the fixed version. The deprecated RFC7523OAuthClientProvider has no issuer= option at all, so organizations should migrate to a supported provider. After upgrading, any stored OAuth client registrations should be cleared once, because registrations created before the patch are not locked to a specific login service and remain exploitable. If a client may already have connected to an untrusted server, its client secret must be rotated and active tokens revoked at the authentication service. On older, unpatched versions there is no workaround other than connecting exclusively to trustworthy MCP servers.

The issuer checks were first included in the September 7 release notes for versions 1.30.0 and 2.2.0, listed as behavior changes rather than a security fix. The formal advisory was published on September 28, the same day Cycode released its detailed writeup. The advisory credits eight reporters, including Cycode's researcher, and states that no attacks exploiting the flaw have been reported. For website owners and businesses relying on web applications, AEU Hosting provides managed WordPress hosting with security-hardened environments that help reduce the risk of credential theft by keeping software and its dependencies current through proactive patching and monitoring.