Critical OAuth Flaw in Microsoft Copilot Python SDK Exposes AI Agent Accounts

Key Takeaways

• A high-severity vulnerability (CVE-2024-34060) was discovered in the Microsoft Copilot Model Context Protocol (MCP) Python SDK.
• The flaw allows a malicious MCP server to steal OAuth authentication tokens, potentially leading to account takeover of AI agent accounts.
• Affected versions range from 1.9.1 to 1.29.1 in the 1.x branch and 2.0.0 to 2.1.1 in the 2.x branch.
• Patches are available in versions 1.30.0 and 2.2.0, with additional configuration required for some OAuth providers.

Critical OAuth Flaw in Microsoft Copilot Python SDK Exposes AI Agent Accounts

A significant security vulnerability has been identified within the official Model Context Protocol (MCP) Python SDK, which underpins Microsoft Copilot’s AI agent functionalities. This high-severity flaw could enable a malicious MCP server to intercept OAuth authentication credentials, leading to the compromise and takeover of AI agent accounts.

The vulnerability primarily impacts HTTP-based MCP clients that utilize OAuth for authentication with trusted identity providers such as Google, Okta, or Microsoft Entra ID, particularly when these clients connect to untrusted MCP servers. The Model Context Protocol itself is an open standard designed to facilitate communication between AI assistants and external tools, APIs, and data sources. When an MCP client requires authentication, it typically initiates an OAuth discovery process to identify the appropriate authorization server for login.

The core issue stems from the SDK’s excessive trust in data provided by the MCP server. This oversight allows an attacker to manipulate sensitive OAuth exchanges, redirecting them to infrastructure under their control.

Exploiting the MCP Python SDK OAuth Flaw

The attack sequence begins when a malicious MCP server responds to a modern authorization-server discovery request with a 404 HTTP status code. This unexpected response forces the vulnerable SDK to revert to a legacy fallback authentication path. Critically, along this fallback path, the SDK accepts OAuth configuration details directly from the malicious MCP server without adequate validation.

Specifically, the SDK fails to verify whether the declared OAuth issuer in the received configuration actually matches the expected legitimate login provider. This lapse enables an attacker to craft a configuration that directs the victim’s browser to a genuine login page (e.g., Google, Okta, Azure AD) for initial authentication, while simultaneously pointing the OAuth token endpoint to a server controlled by the attacker. From the victim’s perspective, the sign-in process appears entirely legitimate, as they interact with the authentic domain of their identity provider.

Upon successful authentication, the compromised SDK inadvertently transmits crucial OAuth elements—including the authorization code, client secret, and the Proof Key for Code Exchange (PKCE) code verifier—to the attacker’s token endpoint. While PKCE is designed to prevent the unauthorized use of stolen authorization codes, the attacker’s receipt of both the authorization code and the corresponding PKCE verifier allows them to complete the OAuth exchange with the legitimate identity provider. This ultimately grants the attacker a valid access token for the victim’s account.

According to Cycode, the vulnerability also compromises credential-binding protections. The SDK would validate stored credentials against an issuer value supplied by the malicious MCP server, potentially enabling an attacker to impersonate the real authorization server. This could trick the SDK into reusing legitimate, stored credentials and sending them to an attacker-controlled endpoint.

The vulnerability affects MCP Python SDK versions 1.9.1 through 1.29.1 in the 1.x branch, and versions 2.0.0 through 2.1.1 in the 2.x branch. Impacted OAuth providers include OAuthClientProvider, ClientCredentialsOAuthProvider, and PrivateKeyJWTOAuthProvider. Older deployments using the deprecated RFC7523OAuthClientProvider may also be at risk.

The severity of the flaw varies depending on the interaction required. For interactive OAuth providers, where user involvement is necessary, the vulnerability received a CVSS score of 6.5. However, the deceptive nature of the login process lowers this barrier significantly. For machine-to-machine providers, which require no user interaction, the rating is a high 7.5. AI agent environments face heightened risk, especially when models autonomously select MCP servers, as threats like compromised registries, typosquatting, prompt injection, DNS hijacking, or network compromises could redirect agents to rogue servers.

What You Should Do

• Upgrade Immediately: Developers should update to MCP Python SDK version 1.30.0 for the 1.x branch or version 2.2.0 for the 2.x branch. These patched versions implement validation of the authorization-server issuer across all discovery paths, rejecting metadata from unexpected providers.
• Configure Explicit Issuers: Organizations utilizing ClientCredentialsOAuthProvider or PrivateKeyJWTOAuthProvider must explicitly configure the expected issuer using the issuer= parameter in their configurations.
• Clear and Rotate Credentials: If there’s a possibility that an application connected to an untrusted MCP server before patching, administrators should clear any older stored OAuth registrations, rotate exposed client secrets, and revoke potentially compromised tokens.
• Understand Scope: Note that MCP servers built with the SDK, local stdio clients, and clients that provide their own tokens or headers are not affected by this vulnerability.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.