MCP Python SDK 1.30.0 and 2.2.0 fix an OAuth credential leak that upgrading alone does not close

The maintainers of the official Model Context Protocol Python SDK published advisory GHSA-qx49-fqc8-xw99 on September 28. Its title states the problem plainly: "OAuth client could send credentials to an authorization server chosen by the MCP server." Severity is High: CVSS 7.5 for unattended providers (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) and 6.5 for the interactive OAuthClientProvider, where a person has to start the sign-in. No CVE had been assigned at the time we read it. The weaknesses listed are CWE-345 and CWE-522.

What went wrong

The SDK's OAuth client, mcp.client.auth, let the MCP server it was talking to influence where the client's OAuth credentials went. The advisory names two causes. First, "the authorization server metadata issuer was not validated on every discovery path." Second, stored or pre-provisioned client credentials were not bound to the authorization server they belonged to.

How exposed a given version was depends on the release line:

• 1.9.1 through 1.29.1: no issuer check and no credential binding on any path.
• 2.0.0 through 2.1.1: both protections existed, but were missing when the server published no protected resource metadata (the legacy fallback) or answered 403 insufficient_scope.
• Both lines: ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider had no way to say which authorization server their credentials were for.

What could leak, per the advisory: the client secret, authorization codes, PKCE code verifiers and, for PrivateKeyJWTOAuthProvider, signed client assertions. The rating is confidentiality only, with no integrity or availability impact.

Who is exposed

An application is affected if it uses the SDK as an HTTP MCP client with OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider or the deprecated 1.x RFC7523OAuthClientProvider as its auth handler, and it "may connect to MCP servers it does not fully trust while holding credentials for a legitimate authorization server."

Not affected: MCP servers built with the SDK, stdio clients, and clients that attach their own tokens or headers. The advisory says that on earlier versions there is no workaround other than connecting OAuth-enabled clients only to servers you trust.

Why upgrading is not the whole fix

The patched releases are mcp 1.30.0 and 2.2.0. They check the expected issuer before fetching any authorization server metadata, reject metadata whose issuer does not match with OAuthFlowError, and discard stored registrations bound to a different issuer. The remediation list then goes further:

1. Upgrade to 1.30.0 or 2.2.0.
2. Set issuer= on ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider. Without it, they "still follow whichever authorization server the MCP server advertises." Omitting it emits a deprecation warning now and becomes an error in 3.0. On 1.30.0 that warning is a DeprecationWarning, which Python hides by default.
3. Move off RFC7523OAuthClientProvider, which has no issuer option.
4. Clear stored OAuth client information once, so the client registers again. Registrations stored without an issuer stay unbound, including everything a 1.x client stored before 1.30.0.
5. Rotate the client secret and revoke tokens for any client that may have connected to an untrusted server.

Point 2 is the trap. A service-to-service client on 1.x that upgrades and sees no errors and no visible warnings is still exposed.

What to check

For a Python MCP client fleet, the audit is short: find the installed mcp version, find every construction of the two machine-to-machine providers, and confirm each passes an issuer. Running the test suite with python -W error::DeprecationWarning will surface any that do not on 1.30.0.

The advisory credits eight reporters: Aviral2642, AlexMelanFromRingo, Gal3m, mrostamipoor, YuvalElbar6, yuvalelbar, RoniGurvich and mahmoudalbustan1.

Primary sources: GitHub advisory GHSA-qx49-fqc8-xw99, modelcontextprotocol/python-sdk, read 2026-10-13.