What happened
The WorkOS analysis published 2026-10-02 (in-window) detailed three MCP ecosystem authentication flaws sharing one root cause (trusting unverified auth input), including this GHSA-qx49-fqc8-xw99 issue in the official MCP Python SDK. The SDK's OAuth client did not consistently validate the issuer and did not bind credentials to the issuing server; fixed in 1.30.0 / 2.2.0, no CVE assigned. The companion rmcp (Rust SDK) flaw CVE-2026-63127 (CVSS 8.2, fixed 2.0.0) and LiteLLM header-trust flaw CVE-2026-59822 (CVSS 8.8, fixed 1.84.0, KEV Sept 2) round out the same pattern.
Why it matters
The MCP ecosystem is the standard agent tool-connection mechanism; a client-side OAuth flaw means connecting an agent to a single malicious MCP server can leak the application's OAuth client credentials and let an attacker obtain tokens for legitimate resources. For AI deployments running unattended machine-to-machine agent connections, this is a direct agent-to-credential-theft path with no user present to notice.
Attack vector
A malicious MCP server tells the client where to log in, and the SDK fails to consistently validate the issuer (RFC 8414) against the address used, and does not bind client registrations/secrets to the server that issued them — so triggering a 404 (legacy fallback) or 403 insufficient_scope makes the SDK transmit the client secret, authorization code, and PKCE verifier to an attacker-controlled token endpoint; the attacker then holds a token for the legitimate resource within its scope
Affected systems
MCP Python SDK mcp 1.9.1 to 1.29.1 and 2.0.0 to 2.1.1 (official Model Context Protocol reference SDK)
Mitigation
Upgrade to mcp 1.30.0 or 2.2.0+; explicitly pass issuer= for ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider (mandatory in 3.0); clear pre-1.30.0 stored registrations and re-register against the expected issuer; rotate secrets if a vulnerable client ever connected to an untrusted server