A newly disclosed flaw in the official Model Context Protocol (MCP) Python SDK can allow a malicious MCP server to redirect OAuth credential exchange to an attacker-controlled token endpoint. For teams building AI applications that connect to external tools and data through MCP, this is a practical patch-and-rotate issue rather than a theoretical protocol concern.
The issue affects MCP clients using HTTP transport and certain OAuth provider implementations in the SDK. In vulnerable versions, a client could be convinced to send sensitive OAuth material — including a client secret, authorization code, and PKCE proof key — to the wrong token endpoint. That combination can allow an attacker to obtain valid access tokens for the legitimate service the application intended to use.
The most important takeaway is simple: upgrade the SDK, configure issuer validation where required, clear old client registrations, and rotate credentials if the client may have connected to untrusted MCP servers.
What the vulnerability allows
MCP is designed to let AI applications talk to tools, APIs, and data sources through a common interface. In many deployments, an MCP client must authenticate to another service using OAuth before it can use those capabilities.
According to the advisory summarized by The Hacker News, the vulnerable SDK behavior occurred when the client asked the MCP server where the relevant authorization server could be found. A malicious MCP server could provide metadata that pointed the client toward an attacker-controlled token endpoint, or otherwise cause credentials meant for a real identity provider to be submitted somewhere else.
That matters because OAuth relies heavily on strict endpoint and issuer trust. If an application sends its client secret and authorization code to the wrong endpoint, the attacker may be able to complete the token exchange against the legitimate service. PKCE is intended to reduce the usefulness of a stolen authorization code, but the protection is undermined if the proof key is also disclosed.
This distinctive risk pattern is token endpoint substitution in MCP OAuth clients, and it is especially relevant for organizations experimenting with agentic AI integrations that can connect to third-party or semi-trusted MCP servers.
Affected versions and fixed releases
The reported affected version ranges are:
| SDK line | Affected versions | Fixed version |
|---|---|---|
| 1.x | 1.9.1 through 1.29.1 | 1.30.0 |
| 2.x | 2.0.0 through 2.1.1 | 2.2.0 |
OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider, or the deprecated 1.x RFC7523OAuthClientProvider.MCP servers built with the SDK are not described as affected by this client-side issue. Local stdio clients and clients that attach their own tokens are also not described as affected in the same way.
Why machine-to-machine clients deserve priority
Interactive OAuth flows still require a user to approve a sign-in, although the approval page may appear legitimate because it belongs to the real identity provider. That makes detection harder, but there is still a human action in the path.
Machine-to-machine providers are more concerning operationally. Client credentials and private key JWT flows are often used by backend services, automation, and integration layers that run without a person present. If such a client can connect to a malicious MCP server while holding credentials for a real service, the attack can happen silently and quickly.
For that reason, security teams should prioritize inventorying non-interactive MCP clients, service accounts, stored OAuth registrations, and any environments where MCP servers can be selected dynamically or supplied by third parties.
Required remediation steps
First, upgrade the official MCP Python SDK to a fixed release: 1.30.0 for the 1.x line or 2.2.0 for the 2.x line.
Second, do not assume upgrading alone is sufficient for every provider. The advisory notes that ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider also need an explicit issuer= value so the client knows which authorization server the credentials belong to. Without that issuer binding, a client may still trust server-supplied authorization metadata too broadly.
Third, clear stored OAuth client registrations after upgrading. Older registrations may not be bound to the expected issuer, so leaving them in place can preserve unsafe trust decisions from the vulnerable behavior.
Fourth, rotate any client secrets and revoke tokens if there is a realistic chance that a client connected to an untrusted or attacker-controlled MCP server. Client secrets are long-lived by design, so exposure is not solved by waiting for an access token to expire.
Detection and hardening guidance
Review application logs for unexpected token endpoint hosts, OAuth discovery requests, or MCP server connections that do not match approved infrastructure. If logs include outbound HTTP destinations, compare them against the expected identity provider domains for each integration.
Teams should also tighten egress controls where possible. MCP clients that only need to authenticate against known identity providers should not be able to submit token requests to arbitrary internet hosts. Network restrictions are not a replacement for the SDK patch, but they can reduce blast radius when client-side validation fails.
Finally, treat MCP server trust as part of your application security model. If an AI application can connect to a server outside your control, that server is not just a passive data source. It may influence authentication flows, tool descriptions, prompts, and downstream actions. Maintain an allowlist for production MCP servers, separate test integrations from production credentials, and avoid using privileged service accounts for exploratory integrations.
Bottom line
This vulnerability is a reminder that AI integration frameworks inherit all the classic risks of API security, identity federation, and supply chain trust. If your organization uses the official MCP Python SDK as an HTTP client with OAuth, patch now, configure issuer validation, clear legacy registrations, and rotate exposed credentials where untrusted MCP servers were reachable.
Source: The Hacker News report