Flaw in the Official MCP Python SDK Lets Malicious Servers Steal OAuth Credentials

The maintainers of the official MCP Python SDK have published a security advisory: a malicious MCP server can trick an application built on the toolkit into surrendering the OAuth credentials it uses to sign in to a genuine service.

The Model Context Protocol (MCP) is an open standard for connecting AI applications to outside tools and data, and this package is its official Python SDK for building servers and clients. Affected versions sent the client secret, the authorization code, and the PKCE proof key to a token endpoint the attacker controlled.

How the theft works

When an MCP client needs to log in, it asks the server it is connecting to where its authorization server can be found. On the affected versions the SDK did not always verify that answer. A malicious server could point it at a login service of its own choosing — either by naming its own server or by serving details that name the user's real service while routing the credentials elsewhere.

The client then sent its secret, its authorization code, and its PKCE proof key to the attacker instead of the real service. The PKCE key is a one-time value meant to keep a stolen authorization code from being reused, so handing it over defeats that protection too.

With the credentials in hand, the attacker can request a valid access token from the genuine login service. Cycode, the firm that reported the flaw, demonstrated the full exchange in a test: the resulting token carries whatever permissions the app was granted. The client secret is long-lived and keeps working until it is rotated.

Who is affected

The flaw is rated high (7.5) for the two providers that run without a person present, and 6.5 for the interactive one, where someone must start the sign-in. Cycode notes that in the interactive case the person approves the genuine login page, so nothing looks amiss. No CVE had been assigned as of September 29.

An app is at risk if it uses the SDK as an HTTP MCP client with one of the OAuth providers (OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider, or the deprecated RFC7523OAuthClientProvider) and can connect to a server it does not control while holding real credentials. MCP servers, local (stdio) clients, and clients that supply their own tokens are unaffected.

What to do

Upgrade to 1.30.0 on the 1.x line or 2.2.0 on the 2.x line. For ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider the upgrade alone is not enough: the advisory says "upgrading changes nothing until you also pass issuer=" to name the service those credentials belong to. The deprecated RFC7523OAuthClientProvider has no such option and should be abandoned.

After upgrading, clear any stored OAuth client registrations once, and if a client may have connected to an untrusted server, rotate its secret and revoke its tokens. The fixes actually shipped on September 7 in the release notes, listed as behavior changes; the advisory followed on September 28. Neither Cycode nor the advisory reports any attacks exploiting the flaw.

Source: The Hacker News