SPR{K}3back to research

A 404 Was Enough to Rewrite Where an MCP Client Sends Its OAuth Login

September 30, 2026 · SPR{K}3 Research

CVE-2026-52869 patched the official Anthropic-maintained MCP Python SDK after Cycode showed that a malicious MCP server, by returning a 404 on the well-known metadata endpoint, could reach a fallback discovery path that skipped issuer validation and shipped the client's OAuth login primitives to attacker infrastructure

On September 28, Cycode's Yuval Elbar published the discovery of an OAuth-flow flaw in the official Anthropic-maintained MCP Python SDK. The Hacker News picked it up the next day; gbhackers, AI Weekly, Arabian Post, Mallory.ai, and Skycloak followed within the day. The tracking ID is CVE-2026-52869, advisory GHSA-jpw9-pfvf-9f58, CVSS 7.5 for machine-to-machine providers and 6.5 for the interactive one.

What the flaw does

An MCP client talking to a remote MCP server needs to authenticate to the same identity provider the server is authorized against. The SDK does that by asking the server where the login provider lives — first at the well-known OAuth metadata endpoint, and, if that endpoint isn't there, along a secondary discovery path.

Per Cycode, the secondary path skipped issuer validation. A malicious MCP server could return a 404 on the well-known endpoint, force the SDK into the fallback, and hand the client an "identity provider" URL under attacker control. The three primitives that then rode the login flow — the client's client secret, the authorization code, and the PKCE proof key — all went to attacker infrastructure while the user saw a legitimate-looking login page. With those three, the attacker can request valid access tokens with the client application's full permissions on the real identity provider.

Cycode's line is the compact one: "The client then sends its secret, its authorization code, and its PKCE proof key to the attacker instead of the real service."

The scope, in numbers

Why the MCP-client tier matters here

For eight straight weeks the security-news cycle for MCP has been about the server tier. To pick just the ones already in the digest cohort: designcomputer mysql_mcp_server CVE-2026-59971 at CVSS 10 on default-bind 0.0.0.0 with no auth; IBM mcp-context-forge python_sandbox_server CVE-2026-53710 at CVSS 10 on raw getattr reaching subprocess.Popen; NetLicensing-MCP CVE-2026-54446 on auth middleware that unconditionally forwarded to the operator's own API key; the PraisonAI cluster; RufRoot; Splunk MCP; Context7. Same architectural pattern in each: MCP server ships auth middleware that silently degrades under a specific condition, and the substrate acts as though it were authenticated.

CVE-2026-52869 closes that cohort on the client tier. The failure isn't a third-party MCP server implementation this time. It is the official SDK the MCP-client ecosystem uses to talk to third-party servers. The condition that trips the failure — a 404 on a well-known endpoint — is one HTTP status code any remote server can produce on demand. Anything that speaks the MCP protocol on the far side gets to trigger it.

That is the reframe. The MCP-server-side cohort has been the story of individual servers each shipping their own auth failures. The client-side story is that a single SDK-tier flaw applies to every MCP client that used a vulnerable release and trusted a third-party server for issuer discovery.

Two things worth checking now

Upgrade mcp — but the real remediation is credential rotation on the identity provider, not the SDK version. Cycode ships upgrade guidance to 1.30.0 or 2.2.0. That closes the future flow. The past is different: any OAuth grant issued through the vulnerable discovery path is a live, valid credential on the real identity provider, and it stays valid until it is audited and rotated there. Skycloak's companion piece walks through pinning the issuer at the client — the general rule is that the OAuth issuer should not be a value the server-under-question got to name. This is the same rule Microsoft named nine days ago in the Storm-3168 writeup about GitHub-issue-leaked service principals: "treat credentials that have been publicly exposed as compromised." CVE-2026-52869 extends the same rule from "the secret leaked" to "the secret was handed to a party you did not authenticate first."

Assume the finding rate on the MCP client side depends on external researchers looking. Eight names on the GHSA credit line for one CVE is a lot of researchers finding the same class of flaw at the same time. The MCP-server-side cohort has been finding CVE-grade issues at roughly the same cadence for two months. If the client-side attention now catches up to the server-side attention, the next few weeks are likely to keep landing SDK-tier finds. The MCP substrate has been shipping fast, and the auth-flow surface is the surface most likely to be underspecified in a fast-shipping substrate.

The 404 trick worked because the SDK was willing to try harder to find an identity provider than it was to verify the one it found. That is the primitive to watch — not this specific CVE, but this specific shape: a client that will fall back to trust when trust was the whole thing you needed to verify.

SPR{K3 is a security research operation that pairs offensive vulnerability research with runtime behavioral defense. Defend is our runtime agent. To talk about a deployment, reach us at support@sprk3.com.