Python MCP SDK updated to 1.30.0 / 2.2.0 to correct vulnerability of OAuth credentials

Python's official SDK maintainers for the Model Context Protocol (MCP) have corrected a vulnerability that allowed a malicious MCP server to deceive a client and have him deliver valid OAuth credentials used to log in to a real service. In the affected versions, the client sent the attacker client secret, authorisation code and the PKCE key (proof key), sufficient elements for the attacker to request access token with the permits that the application had received.

In a technical way, the problem arises in the phase when an MCP client requests the server with which the location of its authorization service is connected. In vulnerable versions, the SDK did not reliably check that the URL or issuer (issuer) of the authorisation server coincided with the one the client expected before following the OAuth exchange. A malicious server could respond by pointing to the attacker-controlled token endpoint - or falsifying metadata to name the legitimate service while directing the requests elsewhere - and thus receiving the customer secret, the authorization code and the PKCE value. The delivery of the PKCE value eliminates the protection that prevents the re-use of an intercepted authorisation code.

Cycode, the firm that reported and demonstrated the problem, made an exchange of evidence and showed that the resulting token carried the same permits as those originally authorized for the application. The ADvisory of the SDK places gravity at 7.5 for suppliers operating without human presence (machine-to@-@ machine) and 6.5 for the interactive supplier, where someone still has to approve the login. Corrections appear in the versions 1.30.0(branch 1.x) and 2.2.0(branch 2.x) of the SDK; the changes were included in version notes published on 7 September and the security notice was released on 28 September, the same day that Cycode published its analysis.

Facts confirmed: The official Python SDK for MCP sent client secret, authorization code and the PKCE proof key to an endpoint controlled by a malicious MCP server in versions prior to 1.30.0 / 2.2.0; Cycode demonstrated the exchange in laboratory; the correction is in 1.30.0 and 2.2.0; the warning on behavior first appeared as a change of behavior in the version notes; there was no CVE assigned to 29 September; there were no reports of its exploits in the field according to the advisory and the Cycode report.

What implementations and roles are affected: the applications that use the SDK asMCP clienton HTTP and using one of these integrated OAuth suppliers: OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider or the obsolete RFC7523OAuthClientProvider from the 1.xseries. For exposure to exist, the customer must be able to connect to an MCP server that does not fully control (e.g. third-party servers). MCP servers built with the SDK, local customers (stdio) and customers who manually attach their own tokens are not affected.

Practical implications: With the stolen credentials an attacker can exchange them for a valid access token in the legitimate authentication service and act with the permits granted to the application. The client secret is usually of long duration, so the exposure remains effective until the secret is broken. In machine-to-machine scenarios this can allow automated access without the need for human interaction; in the case of interactive flow, the user-approved login page can be genuine and not show visible signs of manipulation, so the victim does not perceive anything abnormal during the authorization.

Specific and immediate steps to be taken by those responsible: first, update the SDK to the corrected versions: 1.30.0 for branch 1.x or 2.2.0 for the 2.x. Second, for ClientCredentialsOAuthProvider or PrivateKeyJWTOAuthProvider users, in addition to updating, they must explicitly provide the issue = parameter that links these credentials to the authorization service to which they belong; without that parameter the credentials will continue to accept the address indicated by the MCP server. The obsolete provider RFC7523OAuthClientProvider does not support issue = and should be replaced by one of the other two. Third, after the update, remove only once any OAuth client records stored locally by old versions, because those records were not linked to an issue and would remain unsafe. Finally, if there is a possibility that a client has already connected to an unreliable server, immediately rotate the client secret and revoke tokens and authorizations in the relevant identity service.

As additional temporary mitigation measures: avoid connecting MCP customers to servers that do not control or cannot audit; enable network controls that limit token endpoints destinations to legitimate services; register and review OAuth exchanges and issue exceptions in audit log to detect abnormal activity. Check the identity provider's documentation for customer rotation and revocation procedures and tokens.

Limitations and areas of uncertainty: there is no public evidence that vulnerability has been exploited in production environments to date; however, the lack of reports does not guarantee that there is no undetected abuse. Nor had a CVE been assigned on 29 September - this could change if the maintainers or third parties record the failure at the CVE base later. The impact assessment on specific systems will depend on how each organization manages secrets, customer records and control of external MCP servers.

To better understand why this vulnerability is particularly dangerous, the OAuth model should be reviewed: OAuth 2.0 RFC 6749 and the PKCE mechanisms are designed to ensure that an authorisation code is not reusable by a third party. If the client voluntarily delivers the PKCE key to the attacker, that barrier is cancelled. For technical information and recommendations on the management of warnings in Python (e.g. deprecation that can be hidden by default at 1.30.0), see the official Python warning documentation in docs.python.org. The technical report and the demonstration of the company that reported the problem is available on the Cycode website: Cycode.

In short: if your application uses the official MCP SDK as a client and trusts MCP servers that do not control, update as soon as possible, configure the issue where appropriate, revoke and rotate credentials if there is potential exposure, and review your records and policies of connection to external servers. These specific actions are the only ones that reduce the risk that a malicious MCP server will turn a legitimate interaction into an OAuth credentials commitment.