Cato CTRL™ Threat Research: Two Vulnerabilities in Anthropic’s MCP SDK Enable OAuth Token Theft and Supply Chain Attacks

Executive Summary 

The SolarWinds supply chain attack in 2020 reminded the world how a single weakness in trusted software can have global consequences. That incident reshaped how organizations view software integrity and the importance of securing every stage of the development pipeline.

Cato CTRL and Cato Application Security researchers have identified two vulnerabilities in Anthropic’s Model Context Protocol (MCP) software development kit (SDK) that could expose organizations to a similar class of risk. These flaws, found in the default configuration, could allow threat actors to hijack developer tokens and inject malicious code into automated build and release systems. We demonstrate this risk through a proof of concept in this blog. In environments where MCP-issued tokens are trusted by continuous integration (CI)/continuous delivery (CD) or code-signing processes, this could lead to tampered software being signed and distributed as legitimate updates. The findings highlight how even small configuration gaps can endanger the software supply chain in the era of AI-driven development.

Timeline & Disclosure 

• July 8, 2025: Vulnerabilities reported by the Cato Application Security Team. 
• July 10, 2025: Full technical report and proof-of-concept shared with Anthropic Security. 
• July 11, 2025: Anthropic acknowledged receipt and initiated review with MCP maintainers. 
• September 4, 2025: Anthropic acknowledged our findings and noted that they align with a security scenario described in their official specification under the “Confused Deputy Problem.” They also indicated that efforts are underway to provide clearer guidance and improved default settings in the SDKs to help developers avoid this configuration risk. 

2025 Cato CTRL Threat Report | Download the report

Technical Overview 

How a Misconfigured SDK Can Trigger a Supply Chain Attack 

In many organizations, Anthropic’s MCP SDK serves as the internal OAuth server connecting developers, automation agents, and systems such as Bitbucket or GitHub. The tokens it issues often carry broad permissions that allow developers to clone repositories, trigger builds, upload artifacts, or invoke code-signing steps within a CI/CD process.

Imagine a developer already signed in to their company’s single sign-on (SSO)-backed MCP environment during a normal workday. A malicious website takes advantage of the SDK’s permissive defaults, where sensitive endpoints such as /register, /authorize, and /token accept cross-origin requests from any domain, and redirect URIs are not strictly validated. With a single browser visit, the page silently registers a rogue client, completes the OAuth flow, and steals a valid developer access token.

From that moment, the threat actor effectively becomes the developer within every connected system that trusts MCP-issued tokens. They can access repositories, push code changes, or trigger automated builds that produce signed binaries. In many organizations, especially managed service providers (MSPs) and SaaS vendors, the CI/CD pipeline automatically builds, signs, and publishes these artifacts to a shared update repository that serves multiple customer environments. Because the process relies on authenticated commits and automated signing, the malicious binary passes through the pipeline undetected and is deployed to the vendor’s update server.

When customer tenants or connected systems fetch their next scheduled update from the vendor’s managed service, they may unknowingly install the threat actor’s version. The update is fully signed, fully trusted, and fully compromised, allowing the threat actor’s code to propagate across all customers that depend on the provider’s software distribution channel.

The attack unfolds through a simple but dangerous sequence: 

1. Token Theft: The threat actor exploits insecure OAuth settings to obtain a valid developer token. 
2. Repository Access: Using the stolen token, they access Bitbucket or another source control system. 
3. Build Manipulation: They modify build scripts or source code to embed a malicious payload. 
4. Automated Signing: The CI/CD pipeline, which trusts authenticated pushes, automatically signs the altered binary. 
5. Distribution: The signed artifact is published to the vendor’s update or artifact server, which is used to deliver updates to customer environments. 
6. Propagation: Customer tenants or connected systems automatically download and install the update, causing the compromise to spread through the software supply chain. 

This scenario is especially concerning because nothing is technically broken. The SDK operates as designed, but its permissive default configuration transforms convenience into exposure. There is no zero-day exploit or production vulnerability involved, only a quiet abuse of trust built into automation and identity handling.

The result is a form of trusted identity takeover that ripples across the software supply chain, converting legitimate update infrastructure into an attack channel similar in nature to the SolarWinds incident. In modern development ecosystems driven by agentic AI, automation frameworks, and SDK-based integrations, design defaults that seem harmless can become the first link in a global compromise chain. We illustrate this risk in Figure 1 below.

Figure 1. Illustration from token theft to software supply chain attack 

Anthropic’s MCP SDK analysis 

Our analysis of the Anthropic’s MCP SDK (v1.10.1) revealed two interconnected weaknesses that together enable browser-based token exfiltration and OAuth hijacking.

Insecure CORS Policy (CWE-352) 

By default, the SDK’s /register, /authorize, and /token endpoints are configured with: allow_origins=”*” 

This wildcard setting (Access-Control-Allow-Origin: *) allows any website to send cross-origin requests to sensitive endpoints, enabling a threat actor-controlled webpage to interact directly with the MCP server.

Unvalidated Redirect URIs (CWE-601) 

The SDK client registration process allows arbitrary redirect URIs and does not enforce validation by scheme, origin, or host. 

This means a threat actor can register their own client and set its redirect URI to a domain they control (e.g., http://evil.com), allowing OAuth tokens to be redirected and captured through request parameters in the browser. 

Proof-of-Concept (PoC) 

To demonstrate impact, we created a browser-based HTML exploit hosted on a threat actor-controlled domain. The code used in this proof of concept is shown in Figure 2, Figure 3, Figure 4, and in the video below.

When a victim – who is already logged in to their organization’s SSO-backed MCP OAuth provider – visits the page, the following occurs automatically:

1. A malicious client is registered with a redirect URI pointing to the threat actor’s domain.
2. The page initiates the OAuth /authorize flow.
3. The victim unknowingly grants authorization. 
4. The access token is exchanged via /token and exfiltrated to the threat actor’s server. 

In our PoC, the stolen token granted full Bitbucket API access to the victim’s repositories, which allowed listing, modification, and write actions through authenticated requests.

Figure 2. /register request creating a new OAuth client and returning a client_id due to the insecure CORS configuration

Figure 3. /authorize redirect showing Bitbucket’s OAuth flow accepted the attacker-controlled redirect URI

Figure 4. /token request exchanging the authorization code for access and refresh tokens obtained by the attacker

Conclusion 

These findings underscore how default-permissive SDK configurations can open critical trust boundaries in modern automation environments.

When AI, automation, and developer identity converge, even small oversights in authentication logic can cascade into systemic risks-including software supply chain compromise.

As we continue to integrate AI agents and SDKs deeper into our workflows, the lesson is clear: security must be explicitly configured, not assumed.

 Protections 

For Developers  
Developers deploying the Anthropic MCP SDK should explicitly configure CORS and redirect URI validation to harden OAuth security. 

Secure Redirect URI Validation 

redirect_uri_validation=RedirectUriValidationOptions( 
allowed_schemes=[“https”], 
allowed_hosts=[“myapp.com”, “localhost”] 
) 

This prevents open redirects, authorization code interception, and domain spoofing. 

Secure CORS Configuration 

cors_origins=[“https://myapp.com”, “https://admin.example.com”] 

This prevents cross-origin token theft and cross-site request forgery (CSRF)-based attacks on OAuth endpoints.

Both mitigations are detailed in Anthropic’s MCP documentation and should be enforced whenever the SDK is deployed in production environments.

For Cato Customers 

Beyond the secure configuration of the Anthropic MCP SDK itself, enterprises can further reduce risk by applying GenAI security controls through the Cato SASE Cloud Platform. These controls operate at the network layer and apply to all MCP traffic, including traffic generated by the Anthropic Python SDK or other MCP implementations. 

With these capabilities, enterprises can define security rules that inspect and control AI tool activity across the enterprise.

For example, administrators can create policies that block or alert on remote MCP tool calls such as create, add, or edit.

This approach helps enterprises: 

• Enforce least privilege for AI-driven actions.
• Detect and alert on suspicious prompt usage in real time.
• Maintain detailed audit logs of MCP-related activity across the network.

By combining secure SDK configuration with GenAI security controls, enterprises gain both application-level and network-level protection against token theft, data exposure, and unauthorized AI tool execution.

The post Cato CTRL™ Threat Research: Two Vulnerabilities in Anthropic’s MCP SDK Enable OAuth Token Theft and Supply Chain Attacks appeared first on Cato Networks.