Official MCP Python SDK flaw lets malicious servers steal OAuth credentials

What the flaw is

The official MCP Python SDK has a security flaw that lets a malicious MCP server trick an application into handing over the OAuth credentials it uses to sign in to a real service. Its maintainers described the problem in an advisory on September 28. MCP (Model Context Protocol) is an open standard for connecting AI applications to outside tools and data; this package is its official Python SDK.

On affected versions, a client that needed to sign in asked the MCP server where its authorization server was, and the SDK did not always check the answer. A malicious server could point it at a login service the attacker controlled, and the client sent its client secret, authorization code and PKCE proof key to the attacker instead of the real provider.

Why it matters

The PKCE proof key is a one-time value that stops a stolen authorization code from being reused, so handing it over removes that protection too. With the stolen values the attacker can request a valid access token from the real service.

Cycode, which reported the flaw, demonstrated the full exchange in a test and said the token it received carried whatever permissions the application had been granted. The client secret is long-lived, so it keeps working until changed. The flaw is rated high, 7.5, for the two providers that run without a person present, and 6.5 for the interactive provider. No CVE identifier had been assigned as of September 29.

Who is affected

An application is affected if it uses the SDK as an MCP client over HTTP with OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider or the deprecated 1.x RFC7523OAuthClientProvider, and it can reach a server it does 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.

On the 1.x line, versions 1.9.1 through 1.29.1 are affected and 1.30.0 fixes them; on the 2.x line, 2.0.0 through 2.1.1 are affected and 2.2.0 fixes them.

What to do

Upgrade to 1.30.0 or 2.2.0. In the fixed versions the client checks which login service it expects and refuses any that names a different one.

Applications using ClientCredentialsOAuthProvider or PrivateKeyJWTOAuthProvider must also pass issuer= to name the login service their credentials belong to; upgrading alone changes nothing without it. The deprecated RFC7523OAuthClientProvider has no issuer= option and should be replaced. On older versions, connect only to MCP servers you trust.

The issuer checks appeared in the 1.30.0 and 2.2.0 release notes on September 7 under behaviour changes, not as a security fix; the advisory came on September 28, the same day Cycode published its writeup. No attacks have been reported.