What Is the MCP Python SDK OAuth Flaw? (Sept 29, 2026)

Today's security advisory on the official MCP Python SDK is worth more than a skim: a malicious MCP server could steal an app's OAuth credentials — client secret, authorization code, and the PKCE proof key — by answering one question wrong: "where do I log in?"

What happened: when an MCP client needs to log in, it asks the connected server where the authorization server is. Affected versions (1.9.1–1.29.1, fixed in 1.30.0; 2.0.0–2.1.1, fixed in 2.2.0) didn't always verify that answer. A malicious server names its own token endpoint; the client sends all three secrets to the attacker, who then requests a valid access token from the real login service with the app's full permissions. CVSS 7.5 for the machine-to-machine providers (no human in the loop), 6.5 interactive. No CVE assigned as of Sept 29; no in-the-wild exploitation reported.

The upgrade trap: for ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider, upgrading changes nothing until you also pass issuer= to name the login service those credentials belong to. On 1.30.0 the warning is a standard Python deprecation warning (hidden by default). The deprecated RFC7523OAuthClientProvider has no issuer= option — migrate.

The 5-step remediation: (1) upgrade to 1.30.0/2.2.0; (2) pass issuer= for the two providers; (3) migrate off RFC7523OAuthClientProvider; (4) clear stored OAuth client registrations once; (5) rotate any secrets that may have touched an untrusted server and revoke tokens — client secrets are long-lived.

The bigger picture: this is the OAuth-mix-up attack class that the Sept 28 MCP spec release hardened with mandatory iss validation. The protocol fixed the class; the advisory proves why. And for anyone running agents near money: the stolen token carries the app's full permissions — the authorization surface is the money surface.

Full breakdown with the disclosure timeline, dated receipts, and a live decision-gate test: https://scriptmasterlabs.com/mcp-python-sdk-oauth-flaw