Both Official MCP SDKs Let a Server Pick Where Your OAuth Credentials Go - CVE-2026-104850 and the Python Twin

The short version: until the end of September, an MCP client built on either official SDK would hand its OAuth credentials to whatever authorization server the MCP server told it to use. The Python SDK's advisory, GHSA-qx49-fqc8-xw99, was published on September 28, 2026, and the TypeScript SDK's, GHSA-6qxp-vccf-f47h with CVE-2026-104850, two days later. Both are High, CVSS 7.5, both are fixed, and both say in their own text that upgrading alone does not finish the job.

We covered OAuth for MCP servers when the authorization flow was new. This is the first flaw in that flow to land in the reference client code that most agent hosts build on, rather than in one server. That is what makes it worth a post two weeks after the advisories: the affected population is not users of one package, it is every HTTP MCP client that inherited the SDK's OAuth client and lets its users add remote servers.

What to do now

• Upgrade: Python mcp to 1.30.0 (1.x) or 2.2.0; TypeScript @modelcontextprotocol/sdk to 1.31.0 or @modelcontextprotocol/client to 2.2.0 (plus @modelcontextprotocol/core 2.2.0 if imported directly).
• Pin the issuer on the bundled credential providers: issuer= for ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider in Python; expectedIssuer for ClientCredentialsProvider, PrivateKeyJwtProvider, StaticPrivateKeyJwtProvider and CrossAppAccessProvider in TypeScript. Replace the deprecated Python RFC7523OAuthClientProvider, which has no issuer option.
• Clear or annotate stored credentials. Registrations and tokens saved without an issuer stay unbound after the upgrade, including everything a 1.x client saved before it. Clearing them forces a fresh sign-in; a custom provider should save issuer alongside tokens and client information.
• Rotate if exposure is possible. If a client may have connected to an untrusted MCP server while holding credentials, rotate its client secret or signing key and revoke its tokens at the authorization server.
• Keep interactive sign-ins to trusted servers. The fix does not change where a new sign-in goes.

How the redirection works

An MCP client connecting to an HTTP server with OAuth discovers where to authenticate from metadata the server publishes. The SDKs made two mistakes in that discovery. First, the issuer in the authorization server metadata was not validated on every path. Second, credentials the client already held, whether a secret provisioned at build time or a registration saved from an earlier sign-in, were not bound to the authorization server they came from. Two routes followed from that:

• The malicious server names its own authorization server in its protected resource metadata, and the client goes there with the credentials it holds.
• The malicious server publishes no protected resource metadata, which drops the client into a legacy fallback, and then serves authorization server metadata that presents the user's real server as the issuer. The client believes it is talking to the legitimate issuer and sends it what it has.

What arrives at the attacker's token endpoint depends on the provider in use: a client_secret, an authorization code, a PKCE code_verifier, a signed client assertion from the private-key-JWT provider, and in the TypeScript SDK the refresh token and client secret from an earlier sign-in, sent without any user interaction. The Python advisory scores it 7.5 with no user interaction and notes a 6.5 variant for the interactive provider, where a person has to start the sign-in. In the 2.x Python line the gap was confined to the legacy fallback and to a 403 insufficient_scope response; in 1.x it was every path.

What the fixed versions do, and what they leave to you

The fixed clients determine the expected issuer before fetching any authorization server metadata, refuse metadata whose issuer differs (Python raises OAuthFlowError), and bind stored registrations and tokens to an issuer, discarding a registration bound to a different one so the client registers again. The Python 1.x release notes add that a 5xx or 429 on protected resource metadata now stops the flow rather than falling back.

The part that will be missed is the configuration. The bundled client-credentials and private-key-JWT providers had no field for the authorization server their credentials belong to, so the fix adds one and asks you to fill it in. Omit it in Python and you get a DeprecationWarning, which the interpreter hides by default; it becomes mandatory in 3.0. Credentials already in storage carry no issuer and stay unbound until cleared. And the TypeScript advisory lists three things that remain outside the fix: a new interactive sign-in still goes wherever the MCP server points, direct calls to refreshAuthorization() and exchangeAuthorization() are not covered, and skipIssuerMetadataValidation: true switches the check off. A team that bumps the dependency and ships has done the smaller half.

The two ends of one trust problem

This autumn's HTTP MCP advisories sort into two piles. On the server side, the LiteLLM MCP endpoint accepted invalid bearer tokens and MCP-Atlassian fell back to global credentials, a class we wrote up: an unauthenticated caller gets someone else's access. On the client side, this pair: the client gives its own secrets to the wrong party. Gateways that pass OAuth through sit in the middle and inherit both. The 2026-07-28 specification tightened the authorization text; the reference clients needed to catch up with it, and now have.

What neither advisory can tell you is whether the condition that makes the flaw exploitable ever held in your environment: an affected client, holding real credentials, connected to a server you did not control. Server configurations live in agent settings on developer machines, added one at a time, and a registry entry that changes hands turns a trusted server into an untrusted one without anyone editing a file. The rotation decision rests on an inventory question.

How Anomity surfaces and governs it

See it. The Anomity Endpoint Sensor inventories the MCP servers configured in every agent on every managed machine, including the remote HTTP servers each client is pointed at, so "which clients could have reached a server we do not control, and which credentials do we therefore rotate" is a query rather than a survey. Cloud discovery covers the Google Workspace and GitHub OAuth grants held by AI applications, the other place a stolen agent credential shows up. Metadata only; secrets are redacted on the endpoint.

Enforce before the call runs. On agents that expose a pre-execution hook, such as Claude Code PreToolUse, Anomity can allow, deny or log a tool call before it runs, which is a control on what a connected server can make the agent do rather than on the OAuth handshake itself. Keep the record. Configuration changes and decisions land in a 90-day audit trail and route to SIEM, Slack, email or Jira. Anomity is SOC 2 Type II and complements gateway, EDR, DLP and GRC tooling; it does not replace them. For the full control set, see MCP security explained, and to see which remote MCP servers your fleet actually talks to, book a 30-minute demo.