As reported by The Hacker News, a significant vulnerability in the official Model Context Protocol (MCP) Python SDK could allow a malicious MCP server to exfiltrate OAuth credentials — including the client secret, authorization code, and PKCE proof key — from applications acting as MCP clients. The flaw, reported by Cycode, affects SDK versions 1.9.1 through 1.29.1 (1.x line) and 2.0.0 through 2.1.1 (2.x line). Patches are available in versions 1.30.0 and 2.2.0 respectively.

Security Impact: As reported by The Hacker News, a significant vulnerability in the official Model Context Protocol (MCP) Python SDK could allow a malicious MCP server to exfiltrate OAuth credentials — including the client secret, authorization code, and PKCE proof key — from applications acting as MCP clients.

This is not a routine library bug. It sits at the intersection of two rapidly expanding attack surfaces: the MCP ecosystem — which Anthropic open-sourced and which has become the de facto standard for connecting LLMs to external tools and data — and the OAuth flows that gate access to enterprise SaaS APIs. When an AI agent connects to a third-party MCP server it doesn't control, the trust boundary is already thin. This flaw makes it effectively nonexistent.

Vulnerability Details

IdentifierNo CVE assigned as of September 29, 2026
SeverityHigh (CVSS 7.5) for non-interactive providers; Medium (CVSS 6.5) for interactive provider
Affected ComponentMCP Python SDK — OAuth client providers over HTTP transport
Affected Versions1.x: 1.9.1 – 1.29.1; 2.x: 2.0.0 – 2.1.1
Patched Versions1.30.0 (1.x line); 2.2.0 (2.x line)
Active ExploitationNo confirmed exploitation in the wild reported as of publication date

Why the PKCE Leak Matters

The PKCE (Proof Key for Code Exchange) flow exists specifically to prevent authorization code interception attacks. By handing the PKCE proof key to the attacker alongside the authorization code and client secret, the SDK defeats every layer of OAuth's defense-in-depth model. The attacker doesn't just capture a one-time code — they receive everything needed to replay it against the legitimate authorization server and obtain a fully valid access token.

The client secret is long-lived by design, which means the compromise window extends well beyond the initial interaction. Until the secret is rotated, an attacker can generate fresh tokens at will. For machine-to-machine OAuth providers (which require no human approval), there is no second chance to catch the attack in progress — the credential handoff happens silently.

Who Is Most Exposed

  • AI agent platforms that connect to third-party MCP servers and hold OAuth credentials for enterprise SaaS services (CRM, email, document stores)
  • Machine-to-machine integrations using ClientCredentialsOAuthProvider or PrivateKeyJWTOAuthProvider — the highest CVSS (7.5) path with no human gate
  • Multi-tenant or marketplace-style deployments where users connect to MCP servers they don't operate, which is the core MCP use case

Notably, MCP servers built with the SDK, local stdio clients, and clients that attach externally-managed tokens are not affected by this specific flaw.

Broader Implications

The MCP ecosystem is growing faster than its security model is maturing. This vulnerability exposes a fundamental design tension: the protocol assumes clients can trust server-provided metadata, but the SDK failed to validate that the advertised authorization server matched the credential's intended destination.

As organizations rush to deploy AI agents that interact with SaaS APIs via MCP, they are importing a new class of supply chain risk. Every third-party MCP server a client connects to becomes a potential credential interception point. Security teams need to treat MCP server connections with the same scrutiny as OAuth application-to-application trust relationships — because that's exactly what they are.

Shield53 Recommendations

Immediate Actions:

  • Patch now — Upgrade to MCP Python SDK 1.30.0 (1.x) or 2.2.0 (2.x). There is no safe workaround for the credential leakage path; the patch is the fix.
  • Rotate all OAuth client secrets for any MCP client deployment that connected to third-party servers while running affected versions. Assume credentials were exposed.
  • Audit token logs at your authorization servers for unexpected token issuance patterns, unfamiliar IP addresses, or token requests outside normal application behavior.
  • Inventory MCP connections — Identify every application using the SDK as an HTTP client and document which MCP servers it connects to and which OAuth credentials it holds.

Hardening Measures:

  • Enforce allowlisting at the network layer for MCP client outbound traffic to authorization servers, so even a malicious server can't redirect credential exchanges to attacker-controlled endpoints.
  • Adopt short-lived client secrets and rotate them on a fixed schedule rather than treating them as permanent configuration values.
  • Deploy OAuth token monitoring — Configure anomaly detection on your identity provider for unusual token requests tied to MCP-integrated applications.
  • Restrict MCP server scope — Limit OAuth scopes granted to MCP clients to the minimum necessary, reducing the blast radius of any credential theft.