"upgrading changes nothing until you also pass issuer=" — the advisory warns bluntly, and the detail matters: without an explicit issuer, two OAuth providers in the official MCP Python SDK will still follow login information supplied by whatever MCP server a client connects to, even if that server is malicious.
How a malicious MCP server steals OAuth credentials
The SDK's maintainers say affected versions of the official Model Context Protocol (MCP) Python SDK can be tricked into sending sensitive OAuth data to an attacker-controlled token endpoint. When an MCP client needs to sign in, it asks the server it is talking to where the authorization server (the login service) is located. On vulnerable releases the SDK "did not always check that answer." A malicious server can therefore point the client at an attacker-controlled login endpoint or present contradictory details that name the real service while sending the credentials elsewhere.
The client then transmits three secrets to the attacker: the client secret, the authorization code, and the PKCE proof key. Together these allow the attacker to complete an OAuth token exchange with the real login service and obtain a valid access token. Because the client secret is long-lived it remains usable until rotated, and giving away the PKCE proof key defeats the one-time protection that PKCE offers against reuse of an authorization code.
For interactive sign-ins a person must still approve the login, but Cycode reports that the page the person approves is the genuine login page, so the fraud is not visible to the approver. Two machine-to-machine providers require no human interaction at all.
Who and what is affected
An application is affected if it uses the SDK as an MCP client over HTTP with one of these OAuth providers: OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider, or the deprecated 1.x RFC7523OAuthClientProvider — and the client can connect to an MCP server it does not fully control while holding credentials for a real login service. The advisory specifies that MCP servers built with the SDK, local (stdio) clients, and clients that attach their own tokens are not affected.
The cyber insurance questionnaire just landed. Now what?
SOC 2, HIPAA, insurance renewals - someone has to own security strategy. Nubivance provides fractional CISO leadership without the full-time salary.
Get a security leadThe fix, its caveats, and migration steps
The maintainers released changes in versions 1.30.0 (1.x line) and 2.2.0 (2.x line). In those fixed releases the client determines which login service it expects before fetching any details and will refuse any that name a different service. That behaviour ties client registrations to a specific issuer and prevents the straightforward redirection attack.
But the advisory stresses that upgrading alone is not sufficient for every deployment. If you use ClientCredentialsOAuthProvider or PrivateKeyJWTOAuthProvider, you must also pass issuer= to name the login service those credentials belong to; without issuer= the credentials will continue to follow whichever server the MCP server points them at. On 1.30.0 the warning about this appears as a standard deprecation warning, which Python hides by default and can therefore be easy to miss. The deprecated RFC7523OAuthClientProvider provides no issuer= option at all, so those using it must migrate to one of the other two providers.
After upgrading, the advisory directs teams to clear any stored OAuth client registrations once, because older registrations are not tied to a login service and remain vulnerable. If a client may already have connected to an untrusted server, rotate its client secret and revoke its tokens at the login service. On older SDK releases the advisory says there is no workaround other than connecting only to MCP servers you trust.
Cycode's demonstration, scores, and disclosure timeline
The security firm Cycode reported the flaw and demonstrated a full exchange in a test showing an attacker obtaining a valid access token that carries the same permissions the targeted app had been granted. The advisory notes the client secret is long-lived and thus continues to work until changed.
The flaw received a high severity rating of 7.5 for the two providers that run without a person present; for the interactive provider the advisory scored it 6.5. The issuer checks that remediate the problem shipped in the 1.30.0 and 2.2.0 release notes on September 7 and were listed under behavior changes rather than called out as a security fix. The public advisory and Cycode's writeup followed on September 28; the advisory credits eight reporters, including Cycode's researcher. No CVE had been assigned as of September 29, and neither the advisory nor Cycode reported any active exploitation of the flaw.
What this means for developers, operators, and end users
- Developers and security teams: upgrade to 1.30.0 or 2.2.0, explicitly pass issuer= for ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider, clear stored OAuth client registrations once, and rotate client secrets and revoke tokens if a client may have contacted an untrusted server. Watch for the deprecation warning on 1.30.0, which Python hides by default.
- Enterprise application owners and procurement leaders: identify applications that use the MCP Python SDK as clients over HTTP and confirm which OAuth providers they employ; require upgrades and issuer= configuration where applicable, and avoid relying on the deprecated RFC7523OAuthClientProvider for future deployments.
- End users who approve interactive sign-ins: be aware that a genuine-looking login page can be part of this attack, meaning remediation depends on developer and operator action rather than user detection.
The immediate technical remedy is clear and narrowly scoped: install 1.30.0 or 2.2.0, bind credentials to an issuer, clear legacy registrations, and rotate secrets when necessary. The advisory also underscores an operational lesson: release notes that bury security-relevant behavior changes and deprecation warnings that are hidden by default can delay mitigation. At present no active exploitation has been reported, but the vulnerability enables a straightforward credential theft that remains effective until secrets are changed.
https://thehackernews.com/2026/09/official-mcp-python-sdk-flaw-can-let.html
