CVE-2026-123272 in mcp-go
Summary
by MITRE • 11/05/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/05/2026
The vulnerability identified in Mark3labs mcp-go prior to version 1.2.1 represents a critical flaw within the OAuthHandler.fetchServerMetadata function, specifically categorized under CWE-602: Client-Side Enforcement of Server-Side Security and CWE-798: Use of Hard-coded Credentials when considering the broader context of token misuse. This improper validation issue stems from insufficient verification of resource identifiers during the metadata fetching process in implementations adhering to the Model Context Protocol (MCP). The core technical flaw lies in the application's failure to strictly validate that the resources declared within the well-known OpenID Connect discovery document or MCP server metadata actually correspond to legitimate, authorized endpoints under the control of the declaring entity. By allowing arbitrary resource declarations without rigorous cross-referencing against a trusted registry or strict policy enforcement, the library inadvertently permits malicious actors to manipulate the authorization flow.
In operational terms, this vulnerability enables an attacker hosting a rogue Model Context Protocol server to exploit the trust relationship between clients and servers during the OAuth 2.0 token exchange process. When a client initiates authentication with a malicious MCP server, that server can inject arbitrary resource indicators into its metadata response. According to RFC 8707, which defines how resources are indicated in authorization requests, these identifiers guide the authorization server on which specific APIs or services the issued access tokens should be valid for. Because mcp-go fails to properly validate these declarations before processing them, a malicious server can falsely claim that it represents a different, legitimate MCP server or API service. Consequently, when the client proceeds with authentication based on this misleading metadata, the authorization server issues an access token scoped specifically for the impersonated resource rather than the actual malicious server.
The impact of this misconfiguration is severe as it facilitates unauthorized access to sensitive resources through token replay attacks. An attacker who has obtained a valid access token intended for a protected service can now present that same token to the legitimate target system, believing they are interacting with their own controlled endpoint while actually leveraging credentials meant for another entity. This effectively bypasses authentication controls because the token itself is cryptographically valid and correctly scoped by the authorization server; however, its usage context has been hijacked due to the initial deception at the metadata level. The attacker can thus perform actions on behalf of authenticated users against resources they should not have access to, leading to potential data exfiltration, unauthorized modifications, or complete compromise of the target system's integrity and confidentiality.
This vulnerability aligns with MITRE ATT&CK technique T1652: Impair Defensive Response, as it undermines the security controls designed to restrict token usage scopes, and relates closely to T1078: Valid Accounts if used in conjunction with stolen credentials. It also reflects CWE-345: Insufficient Verification of Data Authenticity, highlighting a failure to ensure that data received from external sources matches expected trust boundaries. To mitigate this risk, organizations must immediately upgrade the Mark3labs mcp-go library to version 1.2.1 or later where these validation checks have been strengthened. Additionally, developers should implement strict allow-listing for resource indicators and perform additional server-side verification of metadata claims before initiating OAuth flows. Security teams should also monitor for anomalous token usage patterns that do not align with the originating client's expected behavior profile to detect potential exploitation attempts in real-time.