Description

Mark3labs mcp-go before v1.2.1 contains an improper validation vulnerability in OAuthHandler.fetchServerMetadata that allows malicious MCP servers to obtain tokens for other resources by declaring arbitrary resources in well-known metadata. Attackers can declare a different MCP server as the RFC 8707 resource indicator, causing the authorization server to mint tokens the attacker replays against that resource.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.0",
  "pubDate": "2026-11-05T19:17:20.713Z",
  "pubdate": "2026-11-05T19:17:20.713Z",
  "executiveSummary": "The Mark3labs mcp-go library, specifically versions prior to 1.2.1, contains an improper validation vulnerability within the OAuthHandler.fetchServerMetadata function. This flaw allows a malicious MCP (Model Context Protocol) server to manipulate the OAuth flow by providing arbitrary RFC 8707 resource indicators in its well-known metadata.\nThe vulnerability allows an attacker-controlled MCP server to deceive the authorization server into issuing tokens intended for legitimate third-party resources. By performing an OAuth token exchange and manipulating the resource scope, the malicious server can obtain access tokens that it is not authorized to hold. These tokens can subsequently be replayed against the target resource, leading to unauthorized data access or service interaction.\nThe risk is significant as it undermines the trust boundary between the MCP client and the resource provider. Exploitation requires the attacker to successfully perform a Man-in-the-Middle or rogue server scenario where the client is induced to interact with a malicious MCP server. Users of the mcp-go library are strongly advised to update to version 1.2.1 or later to implement proper server metadata validation and resource constraint checks.",
  "technicalDetails": "The root cause of this vulnerability lies in the insufficient verification of server-provided metadata within the OAuthHandler.fetchServerMetadata function in the mcp-go library. During the OAuth handshake, the client fetches metadata from the MCP server to determine authorization parameters. In affected versions, the library fails to restrict or validate the resource indicators provided in the well-known configuration.\nThe attack flow begins when an attacker hosts a malicious MCP server designed to serve a crafted .well-known/mcp/configuration endpoint. When the mcp-go client connects to this malicious server, it parses the metadata, which includes a fraudulent RFC 8707 resource indicator pointing to a sensitive, legitimate third-party resource rather than the malicious server itself.\nBecause the OAuthHandler does not validate that the requested resource identifier matches the expected scope or the server's identity, it proceeds to initiate the OAuth authorization flow using the attacker-supplied resource indicator. The authorization server, operating under the assumption that the resource request is legitimate, issues an access token authorized for the target resource. Once the token is returned to the client, the malicious MCP server can intercept or utilize this token to replay requests against the target resource provider.\nThe impact of this exploit is a breakdown in OAuth authorization integrity. The attacker leverages the client's authority to gain access to resources that should be inaccessible to the rogue server. Because this occurs at the protocol negotiation phase, the client remains unaware that the requested scope has been tampered with to target a different resource indicator. The vulnerability exists in the OAuthHandler component, affecting all versions prior to 1.2.1. Exploitation assumes the attacker can trick a client into communicating with a malicious MCP server and does not require pre-existing authentication between the victim client and the attacker."
}