A vulnerability in the official Model Context Protocol Python SDK allowed a malicious MCP server to steal OAuth credentials from any client application connecting over HTTP, Cycode reported and the SDK's maintainers confirmed in a security advisory1,2.
Affected SDK versions sent the client secret, the authorization code, and the PKCE proof key to a token endpoint controlled by the attacker. Cycode demonstrated that the stolen credentials could be used to request a valid access token from the real login service, carrying whatever permissions the application had been granted. Because the client secret is long-lived, it remains usable until rotated.
How the attack works
When an MCP client needs to authenticate, it asks the server it is connecting to where its authorization server can be found. On affected versions, the SDK did not verify that the returned authorization-server endpoint matched the one the client expected, enabling a rogue server to redirect the full credential exchange to infrastructure it controlled.
The flaw is rated 7.5 (high) for the two OAuth providers that operate without human interaction and 6.5 for the interactive provider, where a user must initiate the sign-in flow. No CVE had been assigned as of September 29.
Affected and unaffected configurations
Applications are vulnerable if they use the SDK as an MCP client over HTTP with OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider, or the deprecated 1.x RFC7523OAuthClientProvider, and can connect to a server they do not fully control while holding credentials for a real login service. MCP servers built with the SDK, local stdio clients, and clients that attach their own tokens are not affected.
Affected versions span 1.9.1 through 1.29.1 on the 1.x line and 2.0.0 through 2.1.1 on the 2.x line.
Remediation
The fix shipped in versions 1.30.0 and 2.2.0. In the patched releases, the client determines which authorization server it expects before fetching any metadata and rejects any response naming a different one. For ClientCredentialsOAuthProvider or PrivateKeyJWTOAuthProvider, upgrading alone is insufficient: the issuer parameter must also be passed to bind the credentials to a specific authorization server. The deprecated RFC7523OAuthClientProvider has no issuer option.
Organizations that may have already connected to an untrusted server should rotate their client secrets and revoke tokens at the login service. Older stored OAuth client registrations should be cleared after upgrading because they are not bound to a specific authorization server.
The advisory credits eight reporters, including Cycode's researcher. Neither the advisory nor Cycode has reported any in-the-wild exploitation.
ANALYSIS The vulnerability sits in the reference SDK that defines how MCP clients authenticate, meaning any downstream tool or agent framework that adopted the official package without additional endpoint validation inherited the exposure. The remediation path is not a simple version bump for machine-to-machine providers: operators must also supply the issuer parameter, a step that could delay patching in automated pipelines.