A flaw in the MCP Python SDK let a server nominate your identity provider

FACT. The SDK's OAuth client support, in mcp.client.auth, allowed the MCP server a client was connecting to decide which authorization server received the client's OAuth credentials. Two distinct defects combined:

1. The authorization server metadata issuer was not validated on every discovery path.
2. Stored or pre-provisioned client credentials were not bound to the authorization server they belonged to.

FACT. A malicious or compromised MCP server could therefore direct the client's credentials to a token endpoint of its choosing, in two ways:

• by naming its own authorization server in its protected resource metadata, or
• by publishing none at all and serving metadata that presents the user's real authorization server as the issuer.

FACT. The attacker then received the client_secret, the authorization code, and the PKCE code_verifier meant for the real authorization server — or, with PrivateKeyJWTOAuthProvider, a signed client assertion (private_key_jwt client authentication material) rather than a static secret.

FACT. With those three values, the attacker can redeem them at the real authorization server's token endpoint and receive a genuine access token carrying whatever scopes the application was granted. The client secret is long-lived and keeps working until it is rotated.

FACT — the disclosure timeline.

INTERPRETATION — the 21-day gap is the story. The patched code was in production registries on 7 September. The advisory did not exist until 28 September. For three weeks the safe version was available and nobody, including every automated scanner, knew it was the safe version — because the changelog entry sat under a heading that says "behaviour".

FACT — machine-readable affected ranges as published in the advisory:

• >= 1.9.1, < 1.30.0 — patched in 1.30.0
• >= 2.0.0a1, < 2.2.0 — patched in 2.2.0

FACT — narrative ranges as stated in the advisory and Cycode's write-up:

• 1.9.1 through 1.29.1: "no issuer check and no credential binding on any path. The entire flow is open."
• 2.0.0 through 2.1.1: "both missing whenever the server publishes no protected resource metadata (the legacy fallback) or answers 403 insufficient_scope."
• Both lines, on every path: ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider "had no way to name the authorization server their credentials belong to."

FACT — precision note on the gap. The 2.x line was not uniformly vulnerable. The v2.2.0 release notes state that the protected-resource-metadata path "has done this since 2.0". So 2.0.0–2.1.1 were partially hardened: a cooperating MCP server that publishes protected resource metadata with a wrong issuer was already rejected. What was still broken on 2.x was (a) the legacy fallback path and (b) the 403 insufficient_scope step-up path — precisely the two paths an attacker chooses. And the machine-readable range >= 2.0.0a1 includes the 2.0.0 alpha builds, which the narrative "2.0.0 through 2.1.1" does not spell out.

FACT — is 1.30.0 a backport line? Yes. The v1.30.0 release notes open: "Maintenance release of the 1.x line. 2.x is the current line; 1.x docs are at https://py.sdk.modelcontextprotocol.io/v1/." The fix PRs mirror each other: #3398 on 2.x ("Validate the authorization server metadata issuer on every discovery path") and #3431 on 1.x ("[v1.x] Validate the authorization server metadata issuer on every discovery path"). PyPI shows 1.x and 2.x releases interleaved throughout 2026 (73 releases total), so 1.x is a genuinely maintained maintenance branch, not an abandoned one.

FACT — what the fixed versions actually do. Per the advisory, the fixed client also:

• works out which issuer it expects before fetching any authorization server metadata, on every path;
• refuses metadata whose issuer differs, raising OAuthFlowError;
• binds stored registrations to that issuer, and discards one bound to a different issuer so the client registers again.

Per the v1.30.0 and v2.2.0 release notes, both also: reject on 5xx/429 from protected resource metadata instead of falling back to legacy endpoints; return a non-insufficient_scope 403 to the caller instead of retrying; and follow HTTP redirects only within the endpoint's origin (#3448 on 1.x, #3397 on 2.x, commit c6762e82).

FACT — new behaviour is opt-in-warned, not enforced. Both release notes add a new deprecation warning: ClientCredentialsOAuthProvider / PrivateKeyJWTOAuthProvider without issuer=. The advisory states the advisory-warned state "becomes required in 3.0", and on 1.30.0 it is a DeprecationWarning, which Python hides by default.

FACT — the deprecated 1.x provider is a dead end. RFC7523OAuthClientProvider "has no issuer option". The advisory instructs teams to move to one of the other two providers. Separately, the commit history shows RFC7523OAuthClientProvider was removed from the main line on 2026-07-25 (7163d826, PR #3169), consistent with the advisory describing it as a "1.x" provider.

FACT — the intended, safe discovery sequence (RFC 8414 / RFC 9728 style, as implemented):

1. The MCP client asks the MCP server "who handles your logins?" The server answers with protected resource metadata pointing at an authorization server URL (auth_server_url).
2. The SDK fetches that authorization server's configuration metadata (/.well-known/oauth-authorization-server).
3. The SDK checks that the configuration's issuer field — the login provider's self-declared identity — matches the URL obtained independently in step 1. A malicious server that lies about who its login provider is is caught here.

FACT — the fallback path (legacy). If step 1 fails (the MCP server returns 404), the SDK asks the MCP server itself for the login configuration directly. On that path auth_server_url is None, so the step-3 guard does not run.

FACT — how the attacker satisfies the second control with a lie. The SDK's credential-binding check compares the issuer label on stored credentials against oauth_metadata.issuer — the very field the attacker controls, because the first check never ran. The attacker simply sets issuer to the name of the victim's real identity provider (Google, Okta, Azure AD). The binding check asks "do these credentials belong to this login provider?" and is told yes.

FACT — the third control fails for the same reason. Audience binding stamps the authorization code with "valid only at server X". The SDK only stamps it on the modern discovery path. On the forced fallback path there is no audience stamp, so the authorization code works anywhere.

FACT — why this is practically exploitable and not theoretical. The attacker's configuration points authorization_endpoint at the genuine identity provider. The user is redirected to the real Google / Okta / Azure AD login page at the real URL with a real TLS certificate. There is no phishing page and nothing to notice. After approval, the redirect returns the authorization code to the client; the SDK then POSTs code + client_secret + code_verifier to the token_endpoint from the attacker's metadata. The attacker replays that exact bundle at the real provider's token endpoint and receives a valid access token.

INDEPENDENT EVIDENCE — Cycode's three-configuration proof. Cycode built three test configurations to isolate which control matters:

The Control case is the decisive one: identical attack, the only difference being that the server also answered the discovery request. That single difference makes the issuer check run, the mismatch is detected, and the flow aborts before any credential is sent. In the Escape case the attacker passes the issuer check by naming itself, but then the discovered URL points at the attacker's own origin, which does not match the issuer label on the victim's stored credentials — so the binding check discards those credentials and forces a fresh registration, leaving the attacker with a throwaway identity that has no standing at the victim's real provider.

FACT. Cycode states the proof of concept "does this against a real authorization server with PKCE enforcement" and that the full chain was demonstrated end to end, including calling the userinfo endpoint to confirm takeover.

FACT. MCP is the integration layer through which AI applications reach external tools and data. This flaw is in the client half of that layer — the half enterprises deploy inside their own trust boundary, holding their own corporate credentials.

INTERPRETATION. The structural problem is that in an agent stack, "which server am I allowed to talk to" and "which identity provider do my credentials belong to" are conflated into one untrusted input. A protocol that lets an untrusted counterparty nominate your own identity provider, while skipping the validation that would catch the lie, is a full credential-interception primitive, not a bug class. A single approved click on a genuine login page yields a valid access token plus a reusable client secret.

FACT. The unattended providers are the severe case. ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider run machine-to-machine with no login page and no person present — hence the 7.5 with UI:N. In these, the user-interaction mitigation does not exist at all.

INTERPRETATION — the trust-boundary inversion. Conventional supply-chain risk is code you install executing with your privileges. Here the risk is a server you connect to at runtime extracting credentials from the client that connects. The attack surface is the network and the agent's own tool-selection, not the build pipeline.

FACT — silent to the victim and to monitoring. Cycode and Forkast both note there is no login-prompt anomaly, no failed login, no MFA challenge, no suspicious-IP alert. From the authorization server's perspective the exchange is legitimate: correct client secret, valid code, valid PKCE verifier.

FACT — direct outcomes of the primitive:

• Full OAuth account takeover of the identity the MCP client was acting for, demonstrated end to end by Cycode.
• Theft of a long-lived client secret, usable to mint new tokens at will, independent of the victim.
• Theft of a signed client assertion (private_key_jwt), i.e. the authentication material itself, in the PrivateKeyJWTOAuthProvider case.
• Indefinite persistence via refresh tokens, if the authorization server issues them.
• Lateral movement to every downstream service the stolen OAuth client is authorised to reach.

INTERPRETATION — attack routes that remove the user-interaction caveat entirely. Cycode argues the 6.5 "requires user interaction" score understates risk because the interaction is approving a real login page — the one action users are trained to perform without hesitation. Cycode then names three routes where even that choice is not really the user's:

• Registry / catalogue poisoning. A typosquatted or compromised MCP server directory entry points at the attacker's server. The user picks it from a list that looks curated.
• Prompt injection in agent workflows. Where an agent selects and connects to MCP servers on the user's behalf, a prompt injection from any tool in the chain can steer it at the attacker's server. The user never chose the server, and if the framework auto-presents or auto-approves login flows, the human barrier dissolves.
• DNS hijack or internal compromise. If the attacker controls where a legitimate server name resolves, the client connects believing it is talking to a trusted server, and the login flow starts automatically.

INTERPRETATION. The prompt-injection route is the one specific to the AI-agent era. It converts a network-security bug into a model-behaviour vulnerability with no user in the loop at all — the same class of risk as tool-poisoning and confused-deputy attacks, but with credential theft as the payload instead of data exfiltration.

INTERPRETATION — the escalation path. Account takeover is the foothold. What makes it worse is everything reachable afterwards, and in an enterprise a single OAuth client is often authorised against multiple downstream services — cloud APIs, internal tools, data stores. One stolen secret opens doors across the organisation.

1. Will a CVE be assigned, and by whom? Without one, the fix is invisible to every CVE-driven control. Who is the CNA for a Linux-Foundation-hosted protocol SDK?
2. Why did the fix ship three weeks before the advisory, under "Behaviour changes"? Was this a deliberate coordinated-disclosure decision, or an accidental pre-announcement that the disclosure timeline then had to work around?
3. How many production clients are actually affected? No one has published an adoption figure for mcp.client.auth over HTTP.
4. Will issuer= be enforced by default before 3.0, or only warned about? A DeprecationWarning that Python hides is a weak control; a FutureWarning or a hard default would be stronger. This is an open question for the maintainers.
5. What about other SDKs and other protocol layers? The advisory covers mcp.client.auth in Python. The equivalent OAuth client implementations in the TypeScript/JS SDKs, and in other agent-protocol implementations, were not part of this disclosure and were not checked here.
6. Does the still-open PR #3263 (AS metadata discovery before cold-start token refresh, with issuer-binding check) close a residual gap? It was open at research time.
7. How should agent frameworks handle MCP OAuth now? If a model chooses the server, the issuer= pin is the only thing preventing credential theft — is there emerging best practice for constraining that?
8. Should MCP itself mandate credential-to-issuer binding at the specification level, rather than leaving it as an SDK option that becomes mandatory only in 3.0?
9. Is there any evidence of exploitation that predates disclosure? Cycode's stated impact window is the whole affected version range, which is long. A retrospective log review at authorization servers would be the only way to know.
10. What is the real distribution of client registrations in the wild — dynamic (stored and unbound) versus pre-provisioned with issuer set? This determines how many teams are exposed after upgrading without the pin.

FACT — stated in the advisory and release notes:

• issuer= becomes required in mcp 3.0.
• On affected versions there is no workaround beyond trusting your MCP servers.

PREDICTION — near term (weeks to months):

• Teams that upgraded on 7–28 September from the release notes without reading the advisory will upgrade again when someone notices the issuer= requirement, or when 3.0 forces it. Expect a second, larger migration wave.
• A CVE assignment is plausible but not assured; the GHSA record is already in the format that backfills into one.
• PR #3263 (authorization-server metadata discovery before cold-start token refresh, with issuer-binding check) was still open at research time, so further OAuth-client hardening in mcp.client.auth is likely.

PREDICTION — medium term (6–18 months):

• The first real exploitation campaign, if one occurs, is likely to arrive via one of Cycode's named routes rather than a novel technique — poisoned MCP registry entries, or prompt injection steering an agent to an attacker-controlled server. Expect it to look like a supply-chain compromise rather than an OAuth exploit.
• Other language SDKs for MCP will face equivalent discovery-hardening work, and the absence of a CVE here may mean equivalent issues elsewhere have not been surfaced at all.
• issuer=-style credential-to-issuer binding is likely to become a normative requirement in the MCP specification rather than an SDK-level convenience, driven by exactly this case.
• Detection remains the unsolved part: the attack is silent by design, and no standard control currently distinguishes a stolen-but-valid OAuth exchange from a legitimate one.

What would change this assessment: evidence of exploitation; a CVE assignment pulling in third-party telemetry; a successor finding in the TypeScript SDK or in MCP itself; or mcp 3.0 shipping issuer= as a hard requirement rather than a warning.

MCP's OAuth flaw is not interesting because a popular library had a bug. It is interesting because it shows what happens when an agent protocol starts carrying enterprise credentials before the surrounding machinery catches up — and the machinery did not catch up at all.

Three facts define the story. The controls were all present: issuer validation existed, credential binding existed, audience restriction existed. They were all fed the same unverified input, so they all said "looks good". The fix shipped on 7 September under a heading called "Behaviour changes", and the advisory did not appear until 28 September — and even then it exists only in one repository tab, with no CVE, no NVD record, no OSV record, and structurally no possibility of a CISA KEV listing. For three weeks the safe version of the package was sitting in every registry and every dependency scanner reporting it as ordinary.

The deeper structural point is the trust-boundary inversion. Conventional supply-chain risk is code you install executing with your privileges. This is a server you connect to at runtime extracting credentials from the client that connects — with the victim approving a completely genuine login page at the genuine identity provider, so there is nothing to notice and nothing for monitoring to flag. And the identity obtained is not the user's: it is the application's OAuth client, which in an enterprise is frequently authorised against far more than the single server it was talking to.

That makes the honest framing "the reference SDK of an MCP that Anthropic created and donated to the Linux Foundation's Agentic AI Foundation", maintained in the modelcontextprotocol organisation and disclosed through the MCP security process — not "Anthropic's SDK". The popular headline is wrong about ownership, and it is the ownership question that matters here, because a protocol without a CVE-assignment path or a coordinated advisory channel has nowhere to route a disclosure.

The actionable residue is unglamorous and immediate: upgrade to 1.30.0 or 2.2.0, then — for the two machine-to-machine providers — set issuer=, because the upgrade alone does nothing there and the warning that would tell you is a DeprecationWarning Python hides by default. Clear stored registrations. Rotate the secret and revoke the tokens if an affected client ever met a server you did not fully trust. And for anyone building on this ecosystem: track GHSA-level advisories for agent SDKs directly, because the scanners are not going to tell you, and "no CVE" here meant no signal at all for the entire time the flaw was live.

Key figures, consolidated