- Published on
Official MCP Python SDK Flaw Can Let Malicious Servers Steal OAuth Credentials
- Authors
- Name
- DeepHorus
Maintainers of the official Model Context Protocol Python SDK warned that a malicious MCP server can steal OAuth credentials from vulnerable client applications. Affected releases could send the client secret, authorization code, and PKCE proof key for a real service to an attacker-controlled token endpoint. Fixes are available in SDK versions 1.30.0 and 2.2.0. The issue affects networked clients using built-in OAuth providers, not MCP servers or local stdio integrations.
MCP is an open standard for connecting AI applications to external tools and data, and this package provides official Python building blocks for clients and servers. The vulnerable path requires an HTTP client using OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider, or the deprecated 1.x RFC7523OAuthClientProvider. It also requires credentials for a legitimate service and a connection to an MCP server the application does not fully control. Clients that attach their own tokens are not affected.
When the SDK needs to authenticate, it asks the connected MCP server where the authorization server is located. Vulnerable versions did not consistently verify that the answer matched the expected login service. A malicious server could name its own authorization server, or return genuine service details while directing credentials to a different token endpoint. The client would then disclose its secret, one-time authorization code, and PKCE verifier, defeating the protection PKCE is designed to provide.
Cycode researchers demonstrated the complete exchange in a test and said the attacker could obtain a valid access token carrying the application's granted permissions. Because an OAuth client secret is generally long-lived, it can remain useful until it is rotated. The flaw received a 7.5 high-severity score for the two machine-to-machine providers, while the interactive provider scored 6.5. Even in the interactive case, the victim sees a genuine sign-in page and approves access before the redirected credentials are stolen.
The primary remediation is to upgrade to 1.30.0 on the 1.x line or 2.2.0 on the 2.x line. Those releases determine the expected authorization service before retrieving server metadata and reject metadata that names a different issuer. On older SDK versions, the advisory says there is no workaround other than connecting only to fully trusted MCP servers. The fix therefore closes a protocol-level trust failure rather than merely changing token handling.
Two providers still require configuration after upgrading. Users of ClientCredentialsOAuthProvider or PrivateKeyJWTOAuthProvider must explicitly pass issuer= to identify the service that owns their credentials; without it, those clients can still follow an untrusted server's pointer. On 1.30.0, the resulting deprecation warning is hidden by default, while the deprecated RFC7523OAuthClientProvider has no issuer option and should be replaced. After updating, developers should clear previously stored OAuth client registrations once because legacy records remain unbound to a login service.
If an application may have connected to an untrusted server, operators should rotate its client secret and revoke issued tokens at the real authorization service. The issuer checks shipped on September 7 under behavior changes, and the security advisory followed Cycode's publication on September 28; no CVE had been assigned as of September 29. The episode highlights the risks of delegating OAuth discovery to another protocol server. Future SDK releases are likely to make issuer binding mandatory, surface configuration errors clearly, and treat security-sensitive metadata validation as a default security boundary.
