Overview
A security flaw in the official Model Context Protocol (MCP) Python SDK could allow a malicious MCP server to steal OAuth credentials used by an application to access legitimate services. The vulnerability affected HTTP-based MCP clients using specific OAuth providers and could expose sensitive authentication material, including client secrets, authorisation codes and PKCE proof keys. The issue is particularly relevant as MCP becomes a common way for AI agents to connect to external tools, APIs and enterprise data sources. The deeper lesson is clear: an AI integration should never be allowed to decide where sensitive credentials are sent simply because it controls the discovery process.
How the Credential Theft Worked
When an MCP client connects to a server requiring authentication, the client must determine which identity provider handles the login process. Affected versions of the SDK did not consistently verify that the discovered OAuth provider matched the provider the client expected to use. A malicious MCP server could therefore supply authentication metadata that pointed the login flow towards a legitimate identity provider while directing the final token exchange to infrastructure controlled by the attacker. The user could still see the genuine login page, making the process appear completely legitimate. Behind the scenes, however, the client secret, authorisation code and PKCE verifier could be sent to the attacker.
Why PKCE Did Not Save the Session
PKCE is designed to prevent stolen authorisation codes from being reused by requiring a second one-time proof value. In this case, the attacker could receive both the authorisation code and the PKCE verifier. That effectively neutralised the protection. The stolen information could then be submitted to the real identity provider to obtain a valid access token carrying whatever permissions had originally been granted to the MCP client. Where long-lived client secrets or refresh tokens were involved, the exposure could extend well beyond the initial login session.
MCP Expands the Identity Trust Boundary
MCP is powerful because it allows AI systems to interact with applications, cloud services, data stores and development tools. That same flexibility increases the importance of identity governance. An MCP server should not automatically be trusted simply because an AI application connected to it. The server, identity provider, token endpoint and credential scope all represent separate trust relationships that need independent validation. This becomes even more important when AI agents can discover or connect to tools dynamically rather than through a tightly controlled configuration.
Remediation Requires More Than an Upgrade
Affected environments should upgrade to MCP Python SDK 1.30.0 or 2.2.0 or later. For machine-to-machine providers, the expected issuer should also be explicitly configured so credentials remain bound to the intended identity provider. Previously stored OAuth registrations may need to be cleared, while environments that may have connected to untrusted MCP servers should rotate client secrets and revoke potentially exposed tokens. The goal is to ensure that credentials are bound to a verified identity provider rather than whichever endpoint an MCP server happens to advertise.
Expert in the Cloud Insight
This vulnerability highlights a broader challenge emerging with agentic AI:
AI integrations are becoming part of the identity security architecture.
MCP does not merely connect models to tools. It can connect those tools to real enterprise identities, OAuth tokens and privileged services.
That means discovery, authentication and authorisation flows need the same level of scrutiny as any traditional enterprise application. The critical question is no longer simply whether an AI agent is allowed to use a tool.
It is also:
Who told the agent where to authenticate, and who ultimately received the credentials?
As AI systems become more autonomous, trust must be explicitly verified at every connection boundary.
Dynamic tool discovery should never become dynamic credential trust.
Leave a Reply