MCP Python SDK Flaw Lets a Malicious Server Steer Your OAuth Credentials: Upgrade to 1.30.0 or 2.2.0, Then Pass issuer=

Our verdict: if you build MCP clients in Python with the official MCP Python SDK (not in our directory) and connect over HTTP to servers you don't control, patch today. For two of the four affected providers, upgrading alone changes nothing: you must also pass issuer=. The maintainers rate it High, CVSS 7.5. No attacks have been reported.

What happened

On 28 September 2026 the SDK maintainers published advisory GHSA-qx49-fqc8-xw99, titled "OAuth client could send credentials to an authorization server chosen by the MCP server." Per the advisory, the authorization server metadata issuer was not validated on every discovery path, and stored or pre-provisioned client credentials were not bound to the authorization server they belong to. A malicious MCP server could therefore point a client's credentials at an endpoint it controlled. The Hacker News lists what is exposed: the client secret, the authorization code and the PKCE proof key.

• Severity: CVSS 3.1 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) for the machine-to-machine providers, 6.5 for the interactive provider, which needs user approval. No CVE is assigned.
• Affected providers: OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider, and the deprecated 1.x RFC7523OAuthClientProvider.
• Affected versions: mcp 1.9.1 through 1.29.1, and 2.0.0 through 2.1.1.
• Patched: mcp 1.30.0 and 2.2.0.
• Not affected: MCP servers built with the SDK, stdio clients, and clients that attach their own tokens or headers.
• Exploitation: neither the advisory nor Cycode reports any attacks, according to The Hacker News.

Why it matters

The fix shipped on 7 September 2026, three weeks before the advisory, according to The Hacker News. A routine upgrade may already have pulled it in, which creates false confidence: it only protected you on the interactive provider.

ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider are the machine-to-machine providers, and they hold long-lived client secrets and private keys. On those two, the patched code binds credentials only when you pass an issuer= argument naming the authorization server they belong to. Leave it out and you get a deprecation warning and no protection. Unattended clients holding long-lived secrets, protected only by a warning nobody reads: that is what makes this worth an unscheduled patch.

What changes for you

1. Upgrade mcp to 1.30.0 (1.x) or 2.2.0 (2.x).
2. On ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider, pass issuer= explicitly, for example issuer="https://auth.example.com". It becomes required in 3.0.
3. If you use RFC7523OAuthClientProvider, move off it: it has no issuer= option.
4. Clear stored OAuth registrations once, so clients re-register with issuer binding.
5. If a client may have reached an untrusted MCP server, rotate its client secrets at the authorization server and revoke its tokens.

No tool in our directory is the SDK itself. If you run a Python agent or gateway that speaks MCP over HTTP, check which SDK version it pins.

FAQ

Am I affected if I only build MCP servers? No. The advisory lists MCP servers built with the SDK as not affected, along with stdio clients.

I already upgraded in September. Am I safe? Only on the interactive OAuthClientProvider. On the two machine-to-machine providers you are still exposed until you pass issuer=.

Is there a CVE to track? No. Track it as GHSA-qx49-fqc8-xw99.