MCP Python SDK clients could hand OAuth secrets to a hostile server: upgrade to 1.30.0 or 2.2.0 and set the issuer

MCP Python SDK clients could hand OAuth secrets to a hostile server: upgrade to 1.30.0 or 2.2.0 and set the issuer

28 September 2026 — The maintainers of the official Python SDK for the Model Context Protocol (MCP), the package mcp that many AI-agent products use to talk to tools and data sources, published a high-severity advisory on 28 September 2026 (GHSA-qx49-fqc8-xw99). In affected versions, an MCP server that a client connects to could decide where that client's OAuth credentials were sent. No CVE number had been assigned when the advisory was read on 29 September.

What goes wrong

The SDK's OAuth client did not check the issuer in authorization-server metadata on every discovery path, and it did not bind stored or pre-provisioned credentials to the authorization server they belong to. A malicious or compromised MCP server could name its own authorization server, or serve metadata posing as the user's real one, and then receive the client secret, the authorization code and the PKCE code verifier meant for the real server. With the private-key JWT provider it would receive a signed client assertion instead.

The advisory scores the unattended, machine-to-machine case highest. With the interactive provider a person has to start the sign-in, and the maintainers score that case 6.5.

Who is affected

An application is exposed when both of these hold:

• it uses the SDK as an MCP client over HTTP with OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider or the deprecated 1.x RFC7523OAuthClientProvider;
• it may connect to an MCP server you do not fully trust while holding credentials for a legitimate authorization server.

Affected versions are 1.9.1 to 1.29.1, and 2.0.0 to 2.1.1 on the fallback paths the advisory lists. MCP servers built with the SDK, stdio clients and clients that attach their own tokens are not affected.

The fix needs a code change too

Upgrading to mcp 1.30.0 or 2.2.0 makes the client refuse metadata whose issuer does not match and bind stored registrations to their issuer. But for ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider, the upgrade "changes nothing" until the application also passes issuer= with the real authorization server's address. Leaving it out only raises a deprecation warning, which Python hides by default on 1.30.0; it becomes required in 3.0. The deprecated RFC7523 provider has no issuer option at all.

What to do

• Upgrade mcp to 1.30.0 (1.x) or 2.2.0 (2.x) in every agent or service that acts as an MCP client.
• Pass issuer= on every client-credentials or private-key JWT provider, and move off RFC7523OAuthClientProvider.
• Clear stored OAuth client registrations once so the client registers again bound to the right issuer.
• If a client may have connected to an MCP server you do not control, rotate its client secret and revoke its tokens at the authorization server.
• Ask vendors whose agent products embed the Python SDK which version they ship.

Sources

• GitHub security advisory GHSA-qx49-fqc8-xw99, modelcontextprotocol/python-sdk: OAuth client could send credentials to an authorization server chosen by the MCP server — 28 September 2026
• The Hacker News: Official MCP Python SDK flaw can let servers steal client credentials — 29 September 2026
• modelcontextprotocol/python-sdk release v1.30.0 (read 29 September) — 29 September 2026