MCP OAuth Flaws Shift Risk From Servers to the SDKs Behind Them

What happened

The official Python SDK for the Model Context Protocol (MCP) contained a flaw that let a malicious MCP server hijack an application's OAuth login. Affected versions could be tricked into sending three secrets to a token endpoint controlled by an attacker: the client secret, the authorization code, and the PKCE proof key 1. The maintainers disclosed the issue in a security advisory, and the fix ships in versions 1.30.0 and 2.2.0 1.

The affected range covers mcp 1.9.1 through 1.29.1 and 2.0.0 through 2.1.1 2. The advisory, GHSA-qx49-fqc8-xw99, was published on September 28. It carries a CVSS score of 7.5 and had no CVE assigned at publication 2. Teams using machine-to-machine providers also need to pass an explicit issuer= argument to be fully covered 2. Upgrading the package alone may not finish the job.

Cycode, the security firm that reported the bug, showed that the stolen material is enough to request a valid access token from the real login service. That token carries whatever permissions the application was originally granted 1. The client secret is long-lived, so the exposure lasts well beyond a single session 1. Rotating that secret is a reasonable step for anyone who ran a vulnerable version against untrusted servers.

Not an isolated bug

The Python flaw is one of several MCP authentication problems surfacing at roughly the same time. WorkOS groups it with two others under a single diagnosis: trusting what the other side said 2.

• Rust SDK (rmcp), before 2.0.0. The client never checked that the resource field in a server's protected resource metadata matched the server it was actually talking to. A malicious server could steer the OAuth flow toward a legitimate authorization server and walk off with a token. This is CVE-2026-63127, CVSS 8.2, fixed in 2.0.0 2.
• LiteLLM, before 1.84.0. The trust failure ran the other way. The gateway's MCP endpoint accepted a fabricated Authorization header from a client and let the request through unauthenticated. This is CVE-2026-59822, CVSS 8.8, fixed in 1.84.0. CISA added it to its Known Exploited Vulnerabilities catalog on September 2 2.

The LiteLLM entry deserves attention because CISA's listing means it has been exploited in the wild. The Python and Rust bugs, by contrast, have so far been shown through demonstrations and advisories in the reporting 12. All three, however, rest on the same mistake: one party accepts unverified claims from the other about where tokens should go or who the caller is.

The wider picture: many servers have no auth at all

The SDK flaws matter partly because of what they say about deployments that did adopt OAuth. A separate academic assessment points to an even more basic problem. The study dynamically audited 414 internet-facing MCP servers. It found 68 exploitable vulnerabilities, and 91.8% of the servers lacked OAuth authentication entirely 4.

The two findings sit uneasily together. Most exposed MCP servers skip authentication. The minority that implement it inherit risk from the libraries doing the implementing. Adding OAuth is necessary, but on this evidence it is not sufficient.

Guidance aimed at B2B SaaS vendors covers the remaining design-level traps [3]:

• Token passthrough and confused-deputy attacks. A server that forwards user tokens downstream can be manipulated into using its own elevated credentials. The MCP authorization spec says servers should instead act as OAuth clients and obtain separate, properly scoped tokens 3.
• Over-scoped grants. Integrations often request broad permissions like read:all write:all admin when they need only narrow ones. That turns a single stolen token, or a manipulated agent, into wide access 3.

That second point compounds the SDK bugs. Cycode noted that a stolen token inherits the app's granted permissions 1. Generous scopes therefore directly enlarge the damage from credential theft.

Reading the trend

The pattern is that the attack surface has moved down the stack. When MCP was young, the main question was whether servers bothered with authentication. That question remains largely unanswered for most exposed hosts 4. The newer question is whether the plumbing implementing OAuth correctly verifies issuers, resources, and headers. Three bugs in about a month suggest it often has not 2.

The sources broadly agree on the remedies, and none is novel:

1. Upgrade to the patched SDK and gateway versions, and set the explicit issuer argument where it applies 12.
2. Validate every piece of metadata a counterparty supplies before acting on it 2.
3. Request minimal scopes and obtain separate downstream tokens rather than passing user tokens through 3.

What is new is the cost of skipping them. Agents connect to arbitrary third-party servers, so any one of those servers may be the adversary.

For developers building on agent frameworks, the takeaway is that "supports OAuth" on a feature list says little about safety. The real questions are which SDK version is in use, how it handles untrusted metadata, and how much a leaked token can reach.