Introduction of ourselves

We are the security team from Alibaba Cloud. We have identified a security design flaw in the OAuth mechanism of the MCP protocol. After coordination and confirmation with Anthropic, we are disclosing this type of risk to the community. We hope to reach a consensus with the community on the mitigation approach before finalizing the remediation plan.

Basic knowledge

Glossary of Terms

To avoid confusion in this report, the following key terms are defined:

1. MCP Client
   A client application that implements the MCP protocol. It may exist in desktop or web form (e.g., Claude for Desktop, VS Code, Cursor, etc.).
2. OAuth Client Template
   In AWS Identity Center, an OAuth client template is a predefined configuration used to set restrictions on actual OAuth applications — such as limiting the scope of permissions granted during authorization.
3. OAuth Client
   The actual OAuth client used during the authorization flow when a user authenticates via an MCP client product.
4. Bad MCP Server
   A malicious MCP server forged by an attacker. All data passing through this server can be intercepted or tampered with.
5. Bad OAuth Server
   A malicious OAuth server forged by an attacker. All data flowing through this server can also be intercepted or altered.
6. Metadata
   Refers to the data returned by accessing the .well-known/oauth-authorization-server endpoint, which includes fields such as issuer, authorization_endpoint, token_endpoint, and registration_endpoint.

MCP Protocol Workflow

Note: The following discussion is based on the latest version(draft) of the MCP OAuth protocol: https://modelcontextprotocol.io/specification/draft/basic/authorization
Come from this issue
#205

Impact Description:

Clients implementing the current MCP protocol — such as Claude for Desktop, VS Code, Cursor, Cline, ChatMCP, Cherry Studio (most of which do not natively support OAuth yet and rely on mcp-remote for integration) — are vulnerable to ultra-low-cost phishing attacks that are difficult for users with average security awareness to detect or defend against. This flaw can lead to the theft of OAuth access tokens by attackers, enabling them to gain unauthorized benefits.

Scope of Impact on Product:

1. Services that implement a Remote MCP Server, such as PayPal.
2. Services that provide a public OAuth client, such as Google Cloud Platform (GCP) and Amazon Web Services (AWS).

Summary of Impact:

Extraction of A account accesstoken, and unauthorized access to PayPal invoices and transaction data.The severity of the risk will increase as the MCP protocol becomes more widely adopted.

Attack Scenario:

1. The attacker publishes a malicious article claiming to be the "MCP Configuration Best Practices from XXX Company," luring users into configuring a malicious MCP server address in their client application.
2. After the user configures the malicious server, the OAuth authorization flow is triggered. Since all entities displayed during the authorization process appear legitimate, the user cannot distinguish whether the flow is part of an attack. Upon completing the authorization, the client obtains an access token.
3. The client then sends the access token to the remote Bad MCP Server. Once the attacker-controlled MCP server receives the token, it uses it to exfiltrate the user’s sensitive data.

The normal service workflow is as follows:

However, the attack flow logic during a malicious attack is as follows (the diagram below illustrates the scenario where only the MCP server is spoofed, and the OAuth server remains legitimate):

Root Cause of the Issue:

MCP clients such as VS Code allow users to configure the MCP Server address. The MCP Server can in turn specify the OAuth Server address. During the authorization flow, the client sends sensitive data — including the auth_code and access_token — to the server address configured by the user.

Within the MCP protocol environment, there is a lack of necessary authentication interaction between the MCP client and the authorization server. As a result, the MCP client effectively creates a data exfiltration channel for public clients in the OAuth protocol. Once a user configures a spoofed MCP Server address, an attack can be triggered.

Considering that a Bad MCP Server can use special characters, suffixes, or other domain manipulation techniques to mimic legitimate domains, the phishing risk introduced by this workflow becomes extremely difficult to control effectively.

Attack Cases

Attack Case：PayPal Remote MCP Server

This section demonstrates the attack flow in a reproduction scenario involving a Remote MCP Server integrated with PayPal .
Reproduction Video

Attack Case: Google Cloud Platform (GCP)

Although GCP does not implement a Remote MCP Server, it provides a Public OAuth Client to support use cases where developers can access cloud services without storing long-term credentials (such as permanent access keys) locally.

An attacker can publish a phishing article claiming that GCP supports the MCP protocol. Based on this false premise, users may configure a malicious MCP server address in their client application. As a result, the MCP-based workflow can be exploited to steal the user's OAuth access token.

During this phishing flow, aside from entering the initial forged server address, the user has almost no way of detecting the anomaly. Attackers can easily forge highly realistic domain names, such as: mcp.console.googlecloid.com.

In the past, it was extremely rare for client applications to send an obtained access token to an untrusted remote server after authentication. However, the MCP protocol introduces a large number of such potentially dangerous clients.

Reproduction Video

Attack Case: AWS

Content returned by the malicious .well-known/oauth-authorization-server path (the Auth Server address can also be intercepted via man-in-the-middle here, though it is not required — using a legitimate Auth Server address achieves the same effect):

{
  "issuer": "https://ssoins-72234a1798bd17b3.aws.catgg.com",
  "authorization_endpoint": "https://ssoins-72234a1798bd17b3.aws.catgg.com/authorize",
  "token_endpoint": "https://ssoins-72234a1798bd17b3.aws.catgg.com/token",
  "registration_endpoint": "https://ssoins-72234a1798bd17b3.aws.catgg.com/register",
  "response_types_supported": [
    "code"
  ],
  "response_modes_supported": [
    "query"
  ],
  "grant_types_supported": [
    "authorization_code",
    "refresh_token"
  ],
  "token_endpoint_auth_methods_supported": [
    "none"
  ],
  "code_challenge_methods_supported": [
    "S256"
  ]
}

Note: AWS's SSO URL includes an Identity Center ID , so a phishing attack must also trick the user into entering this ID. However, for services like PayPal and Google Cloud, the SSO URLs are generic and do not require users to input additional information, making the phishing attack significantly easier and more cost-effective.

The attacker successfully obtains the user’s credentials.

Reproduction Video

Severity Analysis

We believe that the increase in phishing risk introduced by the MCP protocol is significant and severe. The main reasons are as follows:
Based on our hands-on attack-defense experience, if a successful phishing attack only requires a user to enter or click on a single link, this should be considered a flaw in the protocol or product design — not something that should be mitigated solely through user security awareness. Most users without background knowledge in network security or offensive/defensive techniques will be unable to distinguish between a legitimate MCP instance and a malicious MCP server.

Shifting the burden of identification onto end users will inevitably lead to large-scale phishing attacks. To illustrate with an analogy: if simply entering or clicking a URL in Exchange could result in the leakage of sensitive email information, it would undoubtedly be classified as a critical defect in the Exchange server itself.

Within the community, this type of security concern has been previously discussed in #265. While we strongly support adding user warnings or notifications as part of the mitigation, we believe that relying solely on alerts is insufficient and irresponsible .

Due to the open nature of the MCP protocol, there is currently no enforcement mechanism to prevent duplication of MCP server names. As a result, victims still face significant difficulty in distinguishing between legitimate and malicious MCP servers.

If this issue is not addressed at the protocol level , and instead shifts the burden of detection onto end-user security awareness, all services implementing OAuth Public Clients and Remote MCP Servers will remain vulnerable. Based on historical precedent, when a security flaw offers sufficient potential gain, attackers will inevitably exploit it at scale.

Given the long-term and often irreversible impact of protocol and client design decisions, failing to address this issue early in the design phase may lead to real-world user compromises in the future — ultimately eroding community confidence in the validity and safety of the MCP protocol.

Within the community, there is another related discussion (which we became aware of through coordination with the Anthropic Security Team): #387
However, based on the proposed solutions in that thread — if mitigation only follows the recommendations from OAuth RFC 0807 by using resource and scope for validation, without imposing restrictions on the callback URL — the fix can still be bypassed.

A fully controlled Bad OAuth Server acting as a man-in-the-middle can forge itself as a legitimate client to the real OAuth server, and simultaneously impersonate a legitimate OAuth server to the client — by manipulating the issuer field and tampering with the callback endpoint.
See also:
#387
#408

So how to fix it?

So here, we have two solutions, and we recommend the first solution.

（Recommended）Solution 1:

It includes two parts:

• Add resource parameter
• Strict verification

Part 1, add resource parameter

Implementation

Based on the standard definition of the OAuth protocol, and in response to access token leakage scenarios, the MCP protocol should require MCP client implementations to include the user-configured MCP server address in the resource parameter when making requests to the OAuth server (e.g., api.example.com, as shown below).

  GET /as/authorization.oauth2?response_type=token
     &client_id=example-client
     &state=XzZaJlcwYew1u0QBrRv_Gw
     &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
     &resource=https%3A%2F%2Fapi.example.com%2Fapp%2F HTTP/1.1
  Host: authorization-server.example.com

For details, please refer to:
https://datatracker.ietf.org/doc/html/rfc9700#name-access-token-leakage-at-the
https://datatracker.ietf.org/doc/html/rfc8707

We are unsure whether the resource field has other intended uses in the standard protocol. If there is a conflict, we recommend that the OAuth protocol extend an audience field to specifically restrict the scope of parties (e.g., MCP servers) that are allowed to use the obtained token.

The OAuth authorization server should display the resource field (or a similar parameter) on the consent page, clearly indicating which MCP server is requesting access — serving as a security warning to the user.

In-depth analysis

If the MCP server and the OAuth server are operated by the same entity, the desktop MCP client should be strictly validated to ensure it provides a legitimate MCP server address. If the provided address does not match the expected one, the authorization request should be denied.

In cases where the MCP server and the OAuth server are operated by different entities — meaning the OAuth server supports third-party client registration — the MCP server address should be required at the time of OAuth client registration. The OAuth server should validate that this address is legitimate and consistent with the one used during the authorization flow. Authorization requests from mismatched or unverified MCP servers should be rejected.

Benefit

This restriction can effectively mitigate the scenario in which an attacker tricks the user into configuring a Bad MCP server address, while the authorization server displayed during the OAuth flow remains legitimate.

Part 2, Strict verification

Why?

To address the more advanced attack scenario — where an attacker not only tricks the user into configuring a malicious MCP server address, but also provides a rogue OAuth server that acts as a man-in-the-middle between the user and the legitimate authorization server — we recommend introducing two additional security controls :

Implementation

1. Verify whether the Authorization Server is trusted. There are two alternative approaches here, choose either one:
   a. (Method A) The MCP client verifies if the issuer value in the redirect URL after OAuth callback matches the Authorization Server address specified by the MCP Server in /.well-known/oauth-protected-resource. If inconsistent, terminate the flow.
   b. (Method B) The MCP client verifies if the issuer value in the redirect URL after OAuth callback matches the authorization_endpoint returned by the Authorization Server in .well-known/oauth-authorization-server. Additionally, ensure that the authorization_endpoint and token_endpoint in .well-known/oauth-authorization-server share the same domain. If not, terminate the flow.
2. OAuth servers should enforce restrictions on the allowed callback URLs when registering a Public OAuth Client for an MCP server:
   a. For dynamically registered clients (e.g., desktop apps), the allowed callback URL should be restricted to loopback addresses such as http://127.0.0.1.
   b. For web-based MCP client applications, the callback URL should be limited to pre-registered, trusted web domains or paths.

This is intended to prevent a malicious OAuth server from tampering with the callback URL and stealing the authorization code.

In-depth analysis

For OAuth service providers that allow public registration (e.g., Okta), if they intend to support third-party MCP server registration while minimizing the impact of "name spoofing," they can implement enterprise verification during the registration process and display risk warnings during the authorization flow to mitigate potential abuse.

These validation mechanisms do not violate the OAuth standard; rather, they align with recommended security practices outlined in the protocol. Since the risk stems from the interaction model specific to the MCP protocol, we believe that MCP can introduce additional requirements for clients and authorization servers — mandating stricter validation and user warnings beyond the baseline OAuth specification.

We assess that the implementation cost for these enhancements on both client applications and AuthServers is acceptable and feasible. These measures can fundamentally address the flaw through systemic controls, rather than placing the burden of detection on end users, whose security awareness is often limited.

Solution 2:

Establish a centralized authority for certification. However, this would compromise the flexibility of the MCP protocol, so this is provided only as a reference and not recommended.

We prefer to adopt the first solution to address this issue. Given that MCP is an open-source protocol, we highly value reaching a consensus with the open-source team, and we welcome discussions on whether the proposed fix is appropriate. Ultimately, we hope to resolve this flaw through standardized means.

Summary

We believe that security should be the top priority in the design of the MCP protocol, to avoid long-term negative impacts on user data privacy and security as AI Agents and related protocols become more widely adopted. As AI becomes increasingly prevalent, overlooking such issues could lead to catastrophic consequences.

Given the far-reaching and often irreversible impact of protocol-level design decisions, we hope to work together with you to design a secure version of the MCP protocol and contribute back to the community. We look forward to further discussion with you.

cc @dsp-ant @dasiths @localden @aaronpk