Critical OAuth Credential Theft Flaw in MCP Python SDK

The flaw existed in how the MCP Python SDK handled OAuth token exchanges with MCP servers. When an application built on the SDK tried to authenticate with a real service using OAuth, it would hand off sensitive credential material—including the client secret, authorization code, and the PKCE proof key—to whatever server it was talking to. A malicious actor running an MCP server could intercept all three components by simply positioning themselves at the network level or by controlling the endpoint the SDK was directed to use. Once those credentials were captured, the attacker could replay them against the legitimate OAuth provider to authenticate as the victim application or user.

The mechanics relied on trust assumptions built into the SDK's design. The SDK assumed that when it initiated an OAuth token exchange, the MCP server it was connected to was trustworthy. In reality, if an attacker controlled that server or intercepted traffic to it, they could modify the response or the request handling to capture the flow in transit. The client secret is normally the most sensitive piece of this material: it proves the application's identity to the OAuth provider. Leaking it to a malicious server means that server can impersonate the application to any OAuth provider that trusts it. The authorization code and PKCE key are shorter-lived, but together they can be used to complete a token request and obtain an access token without ever needing the real user's password.

The advisory specified that versions prior to 1.30.0 contained the flaw. This means any application built on the MCP Python SDK and deployed before the security update was released remains vulnerable if not patched. The scope of harm depends on how widely the SDK is used and whether applications are exposed to untrusted MCP servers—a risk that is higher in environments where MCP servers can be loaded from external sources or where network isolation is weak. Users who only connect to MCP servers they control and trust face lower immediate risk, but the flaw still creates a potential vector if an internal server is ever compromised.

This vulnerability highlights a broader security principle: credentials and authentication material should never be handed to intermediate servers, even if they appear trustworthy. In OAuth flows, the separation between the client (your application), the resource server (where the user's data lives), and the authorization server (where identity is verified) exists for a reason. Any middle layer that gets to see the raw credential material becomes a liability. SDK designers need to enforce this separation in code. Developers using SDKs need to understand what credential material their SDK touches and whether it is being exposed to third-party servers. This is not a flaw unique to MCP; similar issues have appeared in other SDKs when authentication logic is delegated to plugins or external components.

If you maintain or operate an application using the MCP Python SDK, take these steps:

1. Check which version of the MCP Python SDK your application depends on by reviewing your requirements.txt, pyproject.toml, or package lock file.
2. If the version is below 1.30.0, update to 1.30.0 or the latest stable release immediately.
3. Re-run your application's test suite to ensure no regressions occurred after the update.
4. If you cannot update immediately, restrict your MCP server connections to trusted, internal endpoints only and audit logs to see whether any MCP server you've connected to has acted suspiciously.
5. Review any applications that use OAuth on your behalf: if they rely on the vulnerable SDK, request or verify that the maintainer has patched.

The MCP (Model Context Protocol) is a framework for connecting applications to AI models and external services through a standardized server interface. Because MCP servers can be loaded dynamically or from less-trusted sources, they become a potential attack surface. This vulnerability underscores why MCP server vetting, sandboxing, and network segmentation matter. Running MCP servers in isolated network zones or behind proxies that validate their behavior can reduce the blast radius of a compromised or malicious server. Additionally, applications should be designed to assume that any MCP server they talk to might be hostile and should never pass sensitive credentials directly through it.

Credential theft via middleware is a recurring pattern in authentication failures. Research into OAuth implementations (see OWASP OAuth 2.0 threat models and security advisories from providers like Google and Microsoft) shows that leaking client secrets or authorization codes to untrusted intermediaries is a leading cause of account compromise. The SDK maintainers' decision to release a patch quickly and transparently shows good security response practice. However, this incident reveals that assumptions about which parties in a distributed system should see credentials need to be questioned and tested, especially as SDKs integrate more third-party services. Developers should treat any dependency update that fixes an OAuth vulnerability as high priority and test it thoroughly but rapidly.

Your immediate action depends on whether your code depends on the MCP Python SDK. If it does, update today. If you maintain a service that other developers use and that service sits on top of MCP, audit your own credential handling and make sure you are not inadvertently passing sensitive data through untrusted channels. Review the official security advisory from the MCP maintainers for the specific patch details and any workarounds if immediate upgrade is not feasible. In the broader sense, this is a reminder that OAuth flows are fragile and that every layer of your stack that touches authentication material should be scrutinized.

What is MCP and why does it handle OAuth?

MCP (Model Context Protocol) is a framework for connecting applications to external services, including AI models and data sources. Applications using MCP may authenticate with those services using OAuth, which is why the SDK needs to handle OAuth flows. The SDK should shield the application from raw OAuth complexity, but only if it keeps credentials safe.

Do I need to update if I don't use OAuth in my MCP application?

No, this flaw only affects applications that use OAuth authentication. However, you should still check your SDK version and update as part of regular maintenance, since other fixes may be included in newer releases.

Can this flaw be exploited if my MCP server is on a private network?

Private network access reduces risk, but does not eliminate it. If an attacker gains access to your network or if a legitimate server on your network is compromised, the vulnerability can still be exploited. Patching is the only reliable mitigation.

What does PKCE do, and why is leaking the proof key dangerous?

PKCE (Proof Key for Code Exchange) is a security extension to OAuth designed to prevent authorization code interception attacks. Leaking the proof key alongside the authorization code undermines this protection and allows an attacker to exchange the code for a token without needing any other secrets.

Should I rotate my OAuth credentials after this vulnerability?

If you ran an unpatched version of the SDK in production and cannot rule out exposure to a malicious MCP server, rotating your OAuth client secret and any tokens issued during that period is a reasonable precaution.

Source: The Hacker News