MCP Python SDK flaw let rogue servers harvest OAuth secrets

Applications built on the official Model Context Protocol (MCP) Python SDK could be tricked into handing their OAuth login credentials to a malicious server, the SDK's maintainers said in a security advisory published on 29 September 2026.

According to the advisory, reported by The Hacker News, affected versions of the SDK sent the OAuth client secret, the authorisation code, and the PKCE proof key to a token endpoint that an attacker controlled. Those three items are the material a client normally exchanges with a legitimate service to obtain an access token. PKCE, short for Proof Key for Code Exchange, is the mechanism intended to stop an intercepted authorisation code being redeemed by anyone else. In this case, the attacker received the proof key as well, according to the advisory.

The maintainers said the fix is in version 1.30.0 and later. Operators running applications built on earlier releases of the SDK should consult the advisory and upgrade.

MCP is the protocol used to connect AI assistants and agents to external tools and data sources. A client application built on the SDK talks to one or more MCP servers, and those servers can require the client to authenticate to a service on the user's behalf. That design means the trust relationship runs in an unusual direction: the remote server tells the client where to send its credentials. The advisory describes a malicious server abusing exactly that step, so that an application built on the SDK delivers the credentials it uses to log in to a real service into the attacker's hands instead.

The practical consequence described by the maintainers is credential theft rather than direct code execution. A client secret is a long-lived value, and an authorisation code plus the matching proof key is what is needed to complete a token exchange. The advisory does not state that any specific deployment was affected, and no exploitation in the wild has been reported in the source material.

The issue is a reminder that in agent architectures the server side is not automatically a trusted party. Anyone can stand up an MCP server, and a client that follows whatever endpoint a server advertises inherits that server's trustworthiness. Organisations that allow staff or agents to connect to third-party MCP servers may want to keep an inventory of which servers are in use, and which credentials those connections can reach.

The status of the issue is resolved. The maintainers have published fixed builds, and the advisory names 1.30.0 as the first version that is not affected.