Flaw in official MCP Python SDK could leak OAuth credentials

What happened

The Model Context Protocol, or MCP, is an open standard that lets AI applications connect to outside tools and data. Its official Python software development kit (SDK) is the package called mcp, which developers use to build MCP servers and clients. The advisory, published on GitHub on 28 September 2026, says the client part of the SDK let a connected server influence where the client sent its login credentials. The Hacker News reported the story the next day.

The affected versions are 1.9.1 up to 1.29.1 on the older line, and 2.0.0 up to 2.1.1 on the newer line. According to The Hacker News, the issuer checks that fix the problem were first shipped in the 1.30.0 and 2.2.0 releases on 7 September. They were listed as behaviour changes, not as a security fix. The formal advisory came three weeks later, on the same day the security firm Cycode published its own write-up.

The advisory credits eight people who reported the problem, including a researcher from Cycode. The flaw received a score of 7.5, rated high, on the Common Vulnerability Scoring System (CVSS) for the providers that run without a person present. For the interactive provider, where a person must start the sign-in, the score is 6.5. No CVE number had been assigned when The Hacker News reported the story. Neither the advisory nor Cycode reported any attacks using the flaw.

The engineering behind it

Many MCP servers on the internet need the client to log in before they share data. They use OAuth, a common standard for granting access without sharing a password. In OAuth, a separate authorization server checks who the client is and gives it an access token. When an MCP client needs to log in, it asks the MCP server where the authorization server is. The danger is in that question, because the answer comes from a server that may not be trustworthy.

According to the advisory, the affected SDK versions had two weaknesses. First, they did not always check the issuer field in the authorization server's description, which names who is supposed to be issuing tokens. Second, stored client credentials were not tied to the authorization server they belonged to. A malicious MCP server could therefore name the attacker's own login service, or describe the user's real login service while pointing the token request to a different address.

The client would then send its client secret, its authorization code and its PKCE code verifier to the attacker. PKCE is a one-time value meant to stop a stolen authorization code from being reused, so giving it away removes that protection too. The Hacker News reports that Cycode showed the attacker can then get a valid token from the real login service. The client secret is long-lived, so it keeps working until someone changes it.

With the interactive provider, the user still approves a sign-in. Cycode says the page the user sees is the genuine login page, so nothing looks wrong. The two machine-to-machine providers, ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider, do not need a person at all. The fixed versions work out which issuer they expect before fetching any login details. They reject a description that names a different issuer, and they tie each stored registration to its issuer.

Who is affected and what to do

An application is affected only if two things are true. It must be an MCP client that talks over HTTP and uses one of the SDK's OAuth providers. It must also be able to connect to a server it does not fully trust while holding credentials for a real login service. MCP servers built with the SDK are not affected. Local clients that talk through standard input and output, called stdio, are not affected either. Clients that attach their own tokens are also safe.

The advisory says to upgrade to 1.30.0 or 2.2.0. For the two machine-to-machine providers, upgrading alone does nothing until the developer also passes an issuer setting that names the correct login service. On 1.30.0 the warning about this is a deprecation warning, which Python hides by default, so it is easy to miss. The old RFC7523OAuthClientProvider has no issuer option at all, and users should move to one of the newer providers.

After upgrading, developers should clear stored OAuth client registrations once, because older records are not tied to any issuer. If a client may already have connected to an untrusted server, the advisory says to change its client secret and cancel its tokens at the login service. For older versions there is no workaround except connecting only to MCP servers you trust.

What it means in Nepal

We have no source on how many developers in Nepal use this package, so this section is about the skill, not the market. The lesson applies to anyone who builds an AI agent and connects it to tools found online. A server you connect to is a stranger. If your code lets that stranger decide where your secrets go, the stranger can take them. This is true for a student demo and for a company product.

The general rule behind the fix is simple to state. A client should decide in advance who it trusts to issue tokens, and it should refuse anything else. Engineers who check where credentials travel, read security advisories for the libraries they use, and pin library versions in their projects avoid this kind of problem. If you have a project that uses the Python mcp package, the first step is to check which version it uses.