If You Use MCP With Claude, Here Is a Security Patch You Need
If You Use MCP With Claude, Here Is a Security Patch You Need
Most security disclosures arrive wrapped in alarm. Breach notifications, leaked credentials, systems quietly compromised for months before anyone noticed. This one is different. A flaw was found in Anthropic's Model Context Protocol Python SDK, reported through coordinated disclosure, and patched before any known exploitation occurred. The story is not a cautionary tale. It is, as these things go, a good news day.
The vulnerability was discovered by security researcher Yuval Elbar at Cycode, a software supply chain security firm. Elbar reported the issue to Anthropic's MCP team through their established security process. The fix shipped in new SDK releases. The disclosure was published afterward, once users had time to upgrade. That sequence — find, report, fix, publish — is how responsible disclosure is supposed to work, and it does not always go that way.
What MCP Is and Why It Matters Here
Anthropic's Model Context Protocol is an open standard for connecting AI assistants to external tools and data sources. If you are building applications on top of Claude or integrating AI capabilities into existing systems, MCP is very likely part of your stack. The Python SDK is the primary library developers use to implement those connections.
OAuth is the authentication layer that governs how those connections prove identity. When an MCP client connects to a server that requires login credentials, OAuth handles the handshake. Getting that handshake right is a security requirement, not a feature preference. The credentials exchanged in that process — client secrets, authorization codes, proof keys — are the keys to the kingdom for whatever services the client is authorized to access.
The flaw lived in the part of the SDK that manages the discovery and verification of login providers during that handshake. Specifically, it created a condition under which a malicious server could intercept those credentials before they reached their intended destination.
The Shape of the Vulnerability
A logic error, not a missing guard. This is a Computer Science 101 class of flaw. The code compiled cleanly. It ran without errors. It did not crash. It simply did the wrong thing under a specific condition — and that condition was one the attacker could create on purpose.
Think of it like a security checkpoint with a rule that says: "Check ID only if the visitor signed in at the front desk." An attacker who never signs in at the front desk never gets their ID checked. The checkpoint is not broken. The logic is. The guard is doing exactly what they were told — but what they were told had a gap.
That is the pattern here. The SDK's identity verification step was written to run only when a particular piece of data was present. A malicious server could cause that data to be absent by responding to a standard discovery request with a routine server error. The SDK fell back to an alternate path. On that path, the verification step simply did not run.
What that opened up. With verification skipped, the malicious server could supply its own configuration — including where credentials should be sent. The SDK followed those instructions. Authentication credentials, including long-lived client secrets, were redirected to an attacker-controlled endpoint instead of the legitimate login provider.
The user's experience throughout all of this would look completely normal. No warning. No failed login. No suspicious redirect. Just a credential quietly sent to the wrong place.
The safety checks were all present. They simply all trusted the same unverified input — and that input was under the attacker's control.
Who Was Affected
The vulnerability affected developers using the MCP Python SDK as a client over HTTP — specifically those using any of three OAuth provider configurations. It did not affect MCP servers built with the SDK, local connections using the stdio transport, or clients that manage their own authentication headers independently.
The severity rating was issued as High, scoring 7.5 on the standard scale. Cycode's analysis noted that the interactive version of the attack requires a user to initiate a login — which sounds like a meaningful barrier until you consider that the login page the user sees is the real one, from their real identity provider. There is nothing to flag as suspicious. The barrier is effectively zero.
Affected versions: On the 1.x line, versions 1.9.1 through 1.29.1 were exposed. On the 2.x line, versions 2.0.0 through 2.1.1 were affected. Both lines were vulnerable to the core credential interception scenario.
The Fix and What to Do
The patched versions are mcp 2.2.0 on the 2.x line and mcp 1.30.0 on the 1.x line. If you are running the MCP Python SDK as a client over HTTP, upgrading to one of those versions is the immediate action.
Upgrading alone is not the complete picture. Three housekeeping steps accompany the update. If you use pre-provisioned machine-to-machine credentials, you should configure the issuer parameter in your provider setup after upgrading. Stored OAuth registrations created by older SDK versions carry no issuer binding and should be cleared so they are re-created cleanly under the new version. And if your application may have connected to an untrusted MCP server before the upgrade, rotating your client secret and revoking existing tokens at your login provider is the prudent call.
No active exploitation of this vulnerability has been reported. If you have been running affected versions in a controlled environment against servers you fully trust, your risk exposure is low. The urgency scales with how broadly your application connects to external or third-party MCP servers.
No active exploitation has been reported. The patch shipped. Upgrade, clear your stored registrations, and move on.
The Broader Pattern
Elbar's write-up at Cycode closes with an observation worth carrying forward. The underlying vulnerability was not a case of missing safety controls. All the controls existed. The issuer validation logic was there. The credential binding check was there. The audience restriction mechanism was there. What failed was that all of them were fed the same unverified input, and all of them said the input looked fine.
That is a distinct category of flaw from a missing check or a forgotten guard. It is a flaw where the architecture of the checks creates a single point of trust that an attacker can poison once and invalidate everything downstream. Recognizing that pattern is useful well beyond this specific SDK and this specific OAuth implementation.
For the MCP community, the more important takeaway may simply be the disclosure process itself. A serious flaw was found by someone paying close attention. It was reported through proper channels. Anthropic's team worked with the researcher. The fix shipped. The details came out after users could act on them. That is the system working correctly — and in security, that outcome is never guaranteed. When it happens, it is worth noting.
Aaron Rose is a software engineer and technology writer covering system architecture, cloud platforms, and AI policy.