MCP Python SDK: one malicious server was enough to collect your client secret

> TL;DR: A malicious MCP server could trick the official MCP Python SDK client into sending its client secret, authorization code and PKCE proof key to an attacker-controlled token endpoint. The flaw was fixed on September 7 in versions 1.30.0 and 2.2.0 — but the advisory is dated September 28: many deployments are still running affected versions.

The mechanism: the server answers the client's question

The SDK's OAuth flow works like this: the client asks the MCP server where the authorization server is. The server answers. That is where everything hinges.

In the affected versions, the SDK validated that answer insufficiently. A malicious server could return an attacker-controlled token endpoint — and the client would send the client secret, authorization code and PKCE proof key to it.

Cycode reported the flaw and demonstrated a full credential exchange: the stolen credentials are redeemed for a valid access token carrying the application's permissions. And the client secret is long-lived: exchange it once, and you have it for a long time.

Who is affected

Affected providers: OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider, and the deprecated RFC7523OAuthClientProvider on 1.x. CVSS 7.5 for the two non-interactive providers, 6.5 for the interactive provider. No CVE assigned to date, no known active attacks.

What the upgrade does not do

This is the part most teams will miss:

In 1.30.0, the warning is a standard Python deprecation warning, hidden by default. It does not blink anywhere.

What to check right now

The takeaway

In the OAuth flow, the MCP server is the least trustworthy part of the chain — and yet it decides where the client sends its secrets. A client that trusts the discovery answer of any server makes the same mistake as a browser that follows a redirect without checking. The simple rule: an identity must never depend on the answer of an uncontrolled third party.