MCP Python SDK OAuth Flaw Lets Rogue Servers Steal Credentials
TL;DR
- Eight independent researchers are credited in the official advisory, suggesting coordinated multi-party discovery rather than a single reporter.
- The root cause is a legacy 404 fallback path that skipped issuer validation, a design flaw in the reference implementation that propagated to every builder using the SDK.
- Cycode confirmed that PKCE verifiers are also leaked, defeating the control specifically designed to prevent authorization code interception.
"A malicious MCP server could trick an application built on the official MCP Python SDK into handing over the OAuth credentials it uses to log in to a real service," the SDK's maintainers said in a security advisory, reported by The Hacker News.
The flaw sits in how the SDK discovers where to authenticate. When an MCP client needs to log in, it asks the server it is connecting to where its login service, called the authorization server, can be found. On the affected versions (1.9.1 through 1.29.1 in the 1.x line, and 2.0.0 through 2.1.1 in the 2.x line) the SDK did not always check that answer. A malicious server "could point it at a login service of the attacker's choosing, either by naming the attacker's own server or by serving login details that name the user's real service while sending the credentials elsewhere."
Three things leak: the client secret, the authorization code, and the PKCE proof key. Cycode, the security firm that reported the flaw, demonstrated the full exchange in a test and says the resulting token "carries whatever permissions the app was granted." The stolen client secret stays valid until manually rotated.
The advisory rates the bug CVSS 7.5 for non-interactive providers and 6.5 for the interactive one that requires user approval. Fixes ship in 1.30.0 and 2.2.0. No CVE has been assigned and no active exploitation has been reported.
Upgrading alone is not enough for two providers. If you use ClientCredentialsOAuthProvider or PrivateKeyJWTOAuthProvider, the advisory says "upgrading changes nothing until you also pass issuer=" to name the login service those credentials belong to.
What others are reporting
-
GitHub Security Advisory (modelcontextprotocol/python-sdk) Read →
First-party official disclosure from MCP maintainers; names 8 credited researchers and confirms two root causes plus the two-step remediation requirement.
A malicious or compromised MCP server could therefore direct them to a token endpoint of its choosing.
-
Cycode Read →
The discovering researcher's writeup; details 3 bypassed security controls, PoC validation against real IdPs, and post-upgrade credential rotation steps beyond the patch.
A malicious MCP server can hijack the login flow and steal credentials, your client secret, authorization code, and PKCE proof key, enabling full account takeover.
-
Forkast Read →
Focuses on the remediation gap for M2M providers: upgrading changes nothing without also passing issuer= and migrating deprecated options, then rotating credentials retroactively.
The stolen credentials, the OAuth client secret, authorization code, and PKCE proof key, are enough to obtain a valid access token from the real identity provider.
-
GBHackers on Security Read →
Highlights that M2M OAuth providers run without human interaction, leaving automated AI agent pipelines and backend workflows exposed to silent credential theft with no user to notice.
The attacker can then exchange this information at the genuine authorization server to obtain a valid access token.
Originally reported by thehackernews.com
Read the original article →Original headline: MCP Python SDK OAuth Flaw Lets Malicious Servers Steal Credentials, CVSS 7.5