The flaw affects the official Python implementation of MCP, an open protocol originally introduced by Anthropic to connect artificial-intelligence applications with external tools and data. The security advisory rates the vulnerability 7.5 out of 10 for unattended authentication providers and says affected clients could be induced to send sensitive OAuth material to an attacker-controlled endpoint.
Affected releases include versions 1.9.1 through 1.29.1 and the 2. x line from pre-release 2.0.0a1 through 2.1.1. The maintainers fixed the problem in versions 1.30.0 and 2.2.0, released with stricter validation of authorization-server identities and stronger binding of stored credentials to their intended issuer.
Researchers at Cycode, who investigated the weakness, said the attack exploits gaps in OAuth discovery. An MCP client connecting over HTTP must determine which authorization server should handle authentication and where an authorization code should later be exchanged for a token. In vulnerable configurations, a hostile MCP server could influence that process and steer credentials towards infrastructure it controls.
The official advisory says the SDK failed to validate the authorization-server metadata “issuer” on every discovery path. Stored or pre-provisioned client credentials were also not consistently bound to the authorization server for which they had been created. Together, those weaknesses could allow a malicious or compromised MCP server to select the endpoint receiving authentication material.
The exposed information could include a client secret, an authorization code and the PKCE code verifier. For deployments using PrivateKeyJWTOAuthProvider, an attacker could instead obtain a signed client assertion. Cycode said its proof of concept demonstrated that stolen material could be forwarded to the legitimate authorization server to obtain a valid access token.
Cycode described the legacy fallback as central to the exploit. If protected-resource discovery failed, the client could request authorization metadata through an older route without establishing a trusted issuer first. An attacker could then present metadata naming the victim’s legitimate identity provider while supplying a token endpoint under attacker control, defeating the issuer check before credentials were transmitted. The researchers said the attack was reproduced end to end.
A notable feature of the demonstrated attack is that the victim can still be directed to the genuine identity provider’s login page. After authentication, however, the vulnerable client may send the resulting code and related credentials to the attacker’s token endpoint. That makes the weakness different from a conventional phishing attack relying on a counterfeit login page.
The exposure varies between SDK branches. Versions 1.9.1 to 1.29.1 lacked the relevant issuer validation and credential binding across the affected discovery paths. Versions 2.0.0 to 2.1.1 contained protections on the modern path but remained vulnerable when protected-resource metadata was absent or when a server returned a 403 insufficient_scope response.
The advisory identifies OAuthClientProvider, ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider among affected authentication handlers, alongside the deprecated RFC7523OAuthClientProvider in the 1. x branch. MCP servers built with the SDK are not affected by this client-side flaw, nor are local stdio clients or clients that supply their own tokens or headers.
Severity also depends on the authentication method. The 7.5 CVSS score applies to unattended providers, where exploitation requires no user interaction. The interactive OAuthClientProvider scenario is scored at 6.5 because a person must initiate the sign-in process.
Maintainers are advising users to upgrade to version 2.2.0 on the current branch or 1.30.0 on the maintained 1. x branch. Users of ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider must additionally configure the issuer parameter; upgrading alone does not prevent those providers from following an authorization server advertised by the MCP server.
Fixed releases determine the expected issuer before retrieving authorization-server metadata, reject metadata whose issuer does not match and bind stored registrations to that issuer. A stored registration associated with another issuer is discarded so that the client can register again.
Follow Arabian Post
Select Arabian Post as your preferred source on Google and MSN News for trusted business news and Arab politics and updates.
