The Model Context Protocol project has published a high-severity advisory for its official Python SDK: the OAuth client code could be tricked by a malicious MCP server into sending the application's client secret, authorization codes and PKCE verifiers to an authorization server the attacker controls. With those in hand, an attacker can request real access tokens carrying whatever permissions the application was granted.
What happened
The advisory, GHSA-qx49-fqc8-xw99, was published on September 28, 2026 for the mcp package on PyPI. It is rated High with a CVSS 3.1 score of 7.5. No CVE is listed. The Hacker News reports the interactive provider scores lower, at 6.5, and that the fixes actually shipped on September 7.
The root cause is two missing checks in the SDK's OAuth client:
- The
issuerin authorization server metadata was not validated on every discovery path. - Stored or pre-provisioned client credentials were not bound to the authorization server they belong to.
An MCP server can therefore point the client at an attacker-run token endpoint and collect the client_secret, authorization codes, PKCE code_verifier values or signed client assertions. The affected providers are OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider and the deprecated 1.x RFC7523OAuthClientProvider.
| Line | Affected | Fixed | Gap |
|---|---|---|---|
| 1.x | 1.9.1 to 1.29.1 | 1.30.0 | No issuer validation or credential binding on any path |
| 2.x | 2.0.0 to 2.1.1 | 2.2.0 | Missing when the server lacked protected resource metadata or returned 403 insufficient_scope |
According to The Hacker News, the exposure is limited to MCP clients that connect over HTTP. MCP servers, local stdio clients and clients that manage their own tokens are not affected. It also reports no known exploitation, and says security firm Cycode reported the flaw and published a writeup showing the full credential exchange. The advisory credits eight researchers.
Why it matters
This is a classic OAuth mix-up problem showing up in AI-agent plumbing. The client trusted the resource server (the MCP server) to tell it where to log in, and then sent its credentials there. Normally a client secret goes only to the authorization server it was registered with. Here, any MCP server an agent connected to could redirect that secret somewhere else.
For identity teams, the important part is the type of credential that leaks. A client secret is long-lived and is not tied to one user session. If a server-side agent uses client credentials or a private-key JWT to call business APIs, a stolen secret or assertion gives the attacker that application's full delegated access, and it stays valid until someone rotates it. Teams adopting MCP should treat every MCP server they connect to as a third party in the OAuth flow and vet it the way they would vet any other OAuth integration, not as a trusted plugin.
What to check in your environment
- Inventory MCP clients built on the Python SDK. Find every in-house agent, service or tool that depends on the
mcppackage and record which version it pins, including transitive dependencies in agent frameworks. - Upgrade to 1.30.0 or 2.2.0. The Hacker News reports there is no workaround on older versions other than connecting only to MCP servers you trust.
- Set
issuer=explicitly. ForClientCredentialsOAuthProviderandPrivateKeyJWTOAuthProvider, the fixed releases take anissuer=parameter naming the expected authorization server. The advisory says it will be required in 3.0, so set it now. - Clear stored OAuth client registrations after upgrading, per the remediation steps The Hacker News reports, so credentials are re-established against the correct authorization server.
- Rotate secrets and revoke tokens where exposure is possible. If an affected client ever connected to an MCP server you don't control, rotate its client secret or signing key and revoke tokens issued to that client.
- Review IdP logs for those client IDs. Look for token requests from unfamiliar IP addresses or at unusual times for OAuth clients used by MCP tooling.
- Tighten scopes on agent OAuth clients. Whatever this client was granted is what an attacker would get, so cut those apps down to the scopes they actually use.