The official Python SDK for the Model Context Protocol — the open standard connecting AI applications to external tools and data — had a vulnerability that let any malicious MCP server steal the OAuth credentials its clients used to log in to real services. The flaw, disclosed September 28 and tracked as GHSA-qx49-fqc8-xw99, carries a CVSS score of 7.5. No CVE has been assigned.
Cycode, the security firm that reported the flaw, demonstrated the full attack chain in a controlled test. 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, with whatever permissions the application was granted. The client secret is long-lived, so the compromise persists until someone rotates it.
How the Fallback Becomes the Vector
When an MCP client needs to authenticate, it asks the server where to find the authorization server. On affected versions, the SDK did not always verify that answer. Specifically, when a malicious MCP server returns an HTTP 404 for the standard OAuth discovery endpoint (/.well-known/oauth-authorization-server), the SDK falls back to retrieving OAuth configuration directly from the MCP server itself. On this fallback path, the SDK skips issuer validation because the authorization-server URL is not yet set. The check that should have caught a mismatched issuer never runs.
The attacker supplies a token endpoint under their control while falsely declaring the victim’s real identity provider — Google, Okta, Azure AD — as the issuer. The victim authenticates on the genuine login page. Nothing in the flow looks wrong. After approval, the SDK sends the authorization code, client secret, and PKCE proof key to the attacker’s endpoint instead of the real service. The attacker exchanges those credentials at the real authorization server and receives a valid access token.
The Machines That Cannot See the Trap
Interactive clients — where a person initiates the sign-in — are affected, but the more serious risk is to machine-to-machine providers. The two unattended providers, ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider, operate without human oversight. They need no sign-in and no person present. An attacker who compromises or impersonates an MCP server connected to one of these providers can silently harvest credentials from automated AI agents and backend workflows without triggering any visible anomaly.
Standard security monitoring is unlikely to flag the exchange. From the authorization server’s perspective, the authentication looks legitimate: correct client secret, valid authorization code, valid PKCE verifier. The attack produces no login prompt, no error, no deviation from normal OAuth traffic.
The Fix Is Not Just an Upgrade
Affected versions span 1.9.1 through 1.29.1 on the 1.x line and 2.0.0 through 2.1.1 on the 2.x line. The fixed versions are 1.30.0 and 2.2.0. But upgrading alone is not the full fix for the two machine-to-machine providers. The GitHub advisory states that upgrading “changes nothing until you also pass issuer=” to name the login service those credentials belong to. Without it, the providers still follow whichever authorization server the MCP server advertises. The deprecated 1.x RFC7523OAuthClientProvider has no issuer= option at all — teams using it need to migrate to a different provider.
After upgrading, organizations should clear any stored OAuth client registrations (older ones are not tied to an issuer), rotate client secrets, and revoke tokens if a vulnerable client may have connected to an untrusted MCP server. On older versions, the only mitigation is connecting only to MCP servers you fully trust.
The Pattern Under the Protocol
This vulnerability extends a pattern Forkast has tracked across multiple incidents: Azure AI Foundry’s CVSS 10.0 authentication bypass, where the enterprise agent platform’s trust model silently failed; CARBONATO, the first botnet with an AI agent as its command-and-control engine; and SalesBleed, where agents exceeded their instructions to exfiltrate CRM data. Those incidents documented AI capability in offensive contexts. The MCP SDK flaw is different: it targets the protocol layer that agents use to communicate. The attack surface is not the model or the agent’s behavior — it is the plumbing between them.
Cycode coordinated the disclosure with Anthropic’s MCP security team, and the fixes shipped before public disclosure. The advisory credits eight reporters. Neither the advisory nor Cycode reports any attacks using the flaw, and none has been reported elsewhere. But the absence of a CVE — and the fact that the issuer checks shipped in the 1.30.0 and 2.2.0 release notes under behavior changes rather than as a security fix — means the vulnerability may not surface in standard vulnerability scanners or patch prioritization workflows. Enterprises running MCP clients in production should assume exposure until they verify their SDK version and OAuth configuration explicitly.