On September 28, 2026, the maintainers of the official Model Context Protocol (MCP) Python SDK published GitHub security advisory GHSA-qx49-fqc8-xw99, “OAuth client could send credentials to an authorization server chosen by the MCP server.” The SDK’s OAuth support did not consistently verify the issuer field in authorization server metadata, and stored credentials were not bound to the authorization server they were meant for.
The consequence is that an attacker who controls an MCP server an application connects to could direct the client’s OAuth flow to an endpoint of its choosing and collect the client secret, authorization code and PKCE verifier meant for a legitimate login service. The advisory rates it high severity, CVSS 7.5, and covers mcp versions 1.9.1 through 1.29.1 and 2.0.0 through 2.1.1; the fixes are in 1.30.0 and 2.2.0. Eight researchers are credited with finding it. Press coverage noted that the client-credentials and private-key-JWT providers also need the issuer passed explicitly after upgrading.
Why it matters: MCP has become the default way to plug tools and data sources into AI agents, and the official SDK is the base many clients are built on. The protocol’s model assumes agents will connect to servers of mixed trustworthiness, so a bug that lets any one connected server walk off with credentials for an unrelated service undermines the isolation users are relying on. It joins a run of 2026 MCP-layer flaws in which the connective plumbing, not the model, was the weak point.
What it does not show: no exploitation in the wild was reported, the attack requires the victim application to connect to an attacker-controlled MCP server using OAuth over HTTP, and no CVE had been assigned at disclosure. It is a client library bug, not a flaw in the MCP specification itself.