The Model Context Protocol is quickly becoming one of the key integration layers for AI agents, allowing models to connect with external tools, APIs and corporate data. But that connectivity also creates a new security boundary — and a vulnerability in the official MCP Python SDK shows what can happen when that boundary fails.
Researchers at Cycode discovered that a malicious MCP server could trick applications using the official Python SDK into sending it sensitive OAuth credentials, including client secrets, authorization codes and PKCE proof keys. With that information, an attacker could potentially obtain a legitimate access token carrying the permissions originally granted to the application.
The issue affects specific OAuth providers in MCP Python SDK versions 1.9.1 through 1.29.1 and 2.0.0 through 2.1.1. Fixes are available in versions 1.30.0 and 2.2.0. No CVE had been assigned as of September 29, and there is currently no evidence that the vulnerability has been exploited in real-world attacks.
The Problem Was TrustWhen an MCP client needs authentication, it asks the MCP server where the appropriate authorization service is located.
Affected versions of the SDK did not always verify that information correctly.
A malicious MCP server could therefore redirect parts of the OAuth exchange toward infrastructure controlled by an attacker. The client might authenticate against the legitimate service while ultimately transmitting critical authentication material to the malicious endpoint.
The problem is particularly interesting because PKCE, a mechanism specifically designed to protect OAuth authorization codes from interception, could also be undermined. The SDK could send both the authorization code and the PKCE proof key to the attacker, effectively providing both pieces required for the exchange.
The user might see the legitimate authentication page and approve access normally, making the attack difficult to recognize from the login experience alone.
Machine-to-Machine Agents Raise the StakesThe vulnerability becomes even more concerning in autonomous environments.
Two affected providers —ClientCredentialsOAuthProviderandPrivateKeyJWTOAuthProvider— support machine-to-machine authentication where no person needs to approve the login.
That means an AI application interacting with an untrusted MCP server could potentially expose credentials without requiring any user interaction.
This illustrates an emerging problem with agentic infrastructure. OAuth was largely designed around relatively predictable relationships between applications and services. AI agents increasingly discover and communicate with external tools dynamically, creating more opportunities for malicious infrastructure to enter the trust chain.
The security question is no longer simply whether an MCP server provides useful tools. Organizations also need to consider what that server can influence during authentication.
Not Every MCP Deployment Is VulnerableThe issue does not affect every application using MCP.
According to the advisory, affected applications must use the Python SDK as an HTTP MCP client, use one of the vulnerable OAuth providers, connect to a server they do not fully control, and possess credentials associated with a legitimate authorization service.
MCP servers built with the SDK, local clients communicating through stdio, and clients supplying their own tokens are not affected by this vulnerability.
This distinction matters because MCP covers many different deployment architectures, and the flaw specifically concerns how certain client-side OAuth flows establish trust.
Updating Alone May Not Be EnoughDevelopers should upgrade to 1.30.0 for the 1.x branch or 2.2.0 for 2.x.
However, two affected providers require an additional configuration change. Applications usingClientCredentialsOAuthProviderorPrivateKeyJWTOAuthProviderneed to explicitly configure the expected OAuthissuer. Without it, upgrading alone does not provide the intended protection.
Organizations should also clear previously stored OAuth client registrations after upgrading. If an application may already have communicated with an untrusted MCP server, its client secrets should be rotated and existing tokens revoked.
MCP Is Becoming Security-Critical InfrastructureThe vulnerability is important beyond the individual SDK bug.
MCP is increasingly positioned as a standard bridge between AI agents and external systems. Those systems may include source-code repositories, databases, cloud infrastructure, email, enterprise applications and other sensitive resources.
That means vulnerabilities in MCP implementations can potentially cross several trust boundaries at once.
An agent might be securely authenticated to a legitimate corporate service while simultaneously trusting information supplied by an external MCP server. If those relationships are not properly isolated, the external server can become a path toward compromising the legitimate identity.
As agent ecosystems expand, MCP security will therefore need to be treated much like API gateway, identity and service-mesh security.
The lesson from this vulnerability is relatively simple:an MCP server should not be trusted merely because an agent can connect to it. Its ability to influence authentication, credentials and downstream services needs to be constrained independently.
For organizations beginning to deploy large numbers of AI agents, that distinction could become increasingly important.