- Sources: report, HN discussion
- Summary: Cycode reports that a malicious MCP server triggers the SDK's fallback discovery path simply by returning 404, which leaves the issuer value empty so the issuer check never runs, and the server then supplies metadata naming the victim's real identity provider, which satisfies the credential-binding check by assertion. The login page the user approves is the genuine provider at the genuine URL, so there is nothing to notice, while the token endpoint comes from attacker-controlled metadata, and the attacker receives the client secret, the authorization code, and the PKCE verifier. MCP Python SDK versions 1.9.1 through 2.1.1 are affected across
OAuthClientProvider, ClientCredentialsOAuthProvider, and PrivateKeyJWTOAuthProvider, rated High at 7.5, and 6.5 for the interactive provider. - Why it matters: The client secret is long-lived and the fallback path also omits audience binding, so a stolen code works anywhere and rotating tokens alone does not close the exposure.
- Follow-up: Track a fixed MCP Python SDK release, and whether registry poisoning or prompt injection is observed steering clients at attacker-controlled servers, both of which remove the assumption that the user chose the server.
send feedback on this story