CVE-2026-63127 in RMCP SDK
Summary
by MITRE • 09/16/2026
RMCP is an official Rust SDK for the Model Context Protocol. Prior to 2.0.0, the rmcp crate's OAuth implementation in crates/rmcp/src/transport/auth.rs omits the RFC 9728 resource field from ResourceServerMetadata and allows discover_oauth_server_via_resource_metadata to use protected-resource metadata without confirming that the returned resource identifier exactly matches the configured MCP server. A malicious MCP server can publish metadata for a different legitimate MCP resource and its authorization server, causing a victim who connects and completes the authorization flow to obtain a legitimate access token that the client subsequently sends to the malicious server. The attacker can capture the token and impersonate the victim against the legitimate MCP resource within the token's granted scopes. This issue is fixed in version 2.0.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Model Context Protocol (MCP) facilitates interaction between large language models and external data sources or tools, often relying on OAuth 2.1 for secure authentication and authorization. Within this ecosystem, the RMCP Rust SDK serves as a critical implementation of these standards. A significant security flaw was identified in versions prior to 2.0.0 regarding the handling of Resource Server Metadata during the OAuth discovery process. Specifically, the rmcp crate's transport layer failed to enforce strict validation of resource identifiers when determining which authorization server to contact for token acquisition. This oversight stems from an omission of the RFC 9728 resource field in the ResourceServerMetadata structure and a lack of verification that the discovered metadata corresponds exactly to the intended MCP server rather than arbitrary external resources.
The technical vulnerability arises during the automatic discovery phase where clients attempt to locate authorization servers based on provided endpoints or metadata. In the flawed implementation, the function discover_oauth_server_via_resource_metadata would accept protected-resource metadata without verifying that the resource identifier returned in the metadata matches the specific MCP server the user intends to access. This design flaw allows a malicious MCP server to publish its own Resource Server Metadata containing details for a completely different, legitimate third-party service or resource. When an unsuspecting victim initiates a connection with this malicious server, the client's SDK processes the provided metadata and proceeds to authenticate against the authorization server associated with that unrelated legitimate resource.
The operational impact of this vulnerability is severe due to the resulting token confusion attack vector. Upon completing the standard OAuth 2.1 authorization flow, the victim receives an access token issued by the legitimate third-party service for its own resources. However, because the client was tricked into using metadata from a malicious source, it automatically attaches and sends this valid, scoped access token to the malicious MCP server instead of discarding it or requesting a new one appropriate for the local context. The attacker can then capture this token in transit or via log inspection. Since the token is cryptographically valid and issued by a trusted authorization server, the attacker gains the ability to impersonate the victim against the legitimate resource within the scopes granted by that original service. This effectively bypasses authentication controls intended to isolate sessions between different MCP servers.
This vulnerability aligns with CWE-295 Improper Certificate Validation in terms of trust establishment and CWE-613 Insufficient Session Expiration, as it involves mismanagement of credential scope and context. In the MITRE ATT&CK framework, this behavior is characteristic of T1078 Valid Accounts, where an attacker utilizes legitimate credentials to gain access, combined with aspects of T1552 Unsecured Credentials if tokens are intercepted in transit without proper binding or audience validation. The core issue reflects a failure in strict resource identification and scope isolation, which are fundamental principles for preventing token confusion attacks in federated identity systems.
To mitigate this risk, organizations must immediately upgrade the RMCP SDK to version 2.0.0 or later, where the fix ensures that discovered authorization servers correspond strictly to the intended MCP server's registered resources. Developers integrating older versions should implement manual validation of resource identifiers before initiating OAuth flows and avoid relying on automatic discovery mechanisms for untrusted endpoints. Additionally, implementing strict audience claims verification in downstream services can provide a secondary layer of defense by ensuring tokens are only accepted if their target audience matches the expected service identifier. Regular security audits of SDK implementations against RFC 9728 requirements are recommended to prevent similar misconfigurations in future updates.