CVE-2026-63127: OAuth Resource Spoofing and Token Leakage in rmcp SDK

The rmcp crate is the official Rust Software Development Kit (SDK) implementing the Model Context Protocol (MCP). The framework operates as a standardized integration layer enabling Large Language Models (LLMs) to communicate with external data sources, applications, and custom tools. In highly secure environments, these transport connections are governed by robust authentication protocols, typically utilizing OAuth 2.0 frameworks. Specifically, the library implements OAuth Protected Resource Metadata discovery as defined under RFC 9728, which outlines the procedure for clients to automatically discover and trust authorization servers that correspond to given resource endpoints.

A high-severity vulnerability designated as CVE-2026-63127 exists in the client's transport authentication implementation, specifically within crates/rmcp/src/transport/auth.rs. Prior to version 2.0.0, the rmcp library did not validate that the resource identifiers returned during the automated discovery flow matched the target server with which the client established the original connection. This design flaw introduces an unauthenticated remote resource spoofing attack vector that compromises the security guarantees of the OAuth handshake.

This weakness is categorized under CWE-345 (Insufficient Verification of Data Authenticity), representing a failure to validate the binding between the metadata issuer and the actual resource identity. If an attacker hosts or compromises an MCP server, they can trick a connecting client into initiating an authentication flow with a legitimate, trusted third-party authorization server. Upon completion of this flow, the client mistakenly transmits the acquired high-privilege access token directly to the attacker's server, enabling downstream impersonation.

The technical breakdown of the vulnerability centers on the deserialization and subsequent validation logic in the discover_oauth_server_via_resource_metadata routine. According to RFC 9728 Sections 3.3 and 7.3, when a client performs metadata discovery, the resource server must return a JSON payload detailing its capabilities. Critically, the client is required to assert that the resource field inside the metadata response exactly matches the requested resource URL. This mechanism is critical to prevent resource server impersonation.

In affected versions of the rmcp crate, the JSON deserialization model ResourceServerMetadata did not contain the resource field. The library discarded this key entirely during deserialization because the struct was mapped using serde macro traits without a corresponding field placeholder. Consequently, the application logic was blind to the resource claim returned by the server, rendering it incapable of performing any validation checks.

Because the library completely ignored this property, the client did not perform the essential matching of domains, ports, or paths. If a user connected their client to an untrusted or malicious server, the server could instruct the client to authenticate against an arbitrary, highly-trusted authorization server. The validation layer failed to check the legitimacy of this binding, allowing the client to execute the entire OAuth PKCE workflow against the real authorization server under the false context of the untrusted connection.

To understand the precise code-level flaw, we must analyze the structure of the deserialization schema in crates/rmcp/src/transport/auth.rs prior to the patch.

// Vulnerable Struct Definition
#[derive(Debug, Clone, Deserialize)]
struct ResourceServerMetadata {
    // Note the complete absence of the "resource" field
    authorization_server: Option<String>,
    authorization_servers: Option<Vec<String>>,
    scopes_supported: Option<Vec<String>>,
}

The absence of the resource field meant any server-side value assigned to it was dropped during the deserialization cycle. To fix this, the patch introduces the resource field and implements a strict check in AuthorizationManager::discover_metadata.

// Patched Struct Definition
#[derive(Debug, Clone, Deserialize)]
struct ResourceServerMetadata {
    resource: Option<String>,
    authorization_server: Option<String>,
    authorization_servers: Option<Vec<String>>,
    scopes_supported: Option<Vec<String>>,
}

The validation helper function validate_resource_metadata_resource checks whether the target is valid:

impl AuthorizationManager {
    fn validate_resource_metadata_resource(
        &self,
        metadata: &ResourceServerMetadata,
    ) -> Result<(), AuthError> {
        let Some(resource) = metadata.resource.as_deref() else {
            return Err(AuthError::MetadataError(
                "Protected resource metadata missing required resource field".to_string(),
            ));
        };
 
        if !Self::resource_identifiers_match(self.base_url.as_str(), resource) {
            return Err(AuthError::MetadataError(format!(
                "Protected resource metadata resource mismatch: expected '{}', got '{}'",
                self.base_url, resource
            )));
        }
 
        Ok(())
    }
}

Furthermore, the matching logic utilizes resource_identifiers_match and is_root_resource_identifier to verify root path uniformity. It allows discrepancies limited strictly to root-level trailing slashes, thereby protecting against basic formatting differences while rejecting path traversal or cross-domain deviations.

Exploiting CVE-2026-63127 relies on standard HTTP manipulation techniques without requiring any advanced host penetration. First, the attacker registers or compromises a public or accessible endpoint, acting as a malicious Model Context Protocol server located at https://attacker-mcp.io. The attacker then waits for a victim client—such as an LLM agent framework configured with the rmcp crate and OAuth features enabled—to initiate a connection.

When the victim connects to the attacker-controlled server, the server responds with an HTTP 401 Unauthorized status code accompanied by a customized challenge header: WWW-Authenticate: Bearer resource_metadata="https://attacker-mcp.io/.well-known/oauth-protected-resource". This header directs the vulnerable client to perform metadata discovery at the specified path.

When the client retrieves the metadata, the attacker's server serves a crafted JSON response:

{
  "resource": "https://trusted-mcp.com",
  "authorization_servers": ["https://auth.trusted-mcp.com"]
}

The client deserializes this metadata, parses the legitimate authorization server list, and starts the login handshake. The victim's browser is launched to complete the authentication against https://auth.trusted-mcp.com.

After the victim successfully signs in and authorizes the application, the client completes the authorization code exchange to fetch an access token. Because the underlying connection state is still bound to https://attacker-mcp.io, the client transmits the legitimate bearer token to the attacker's endpoint. The attacker intercepts this token and can immediately perform authenticated operations on the target https://trusted-mcp.com server within the permissions granted by the stolen scopes.

The impact of this resource spoofing flaw is substantial, representing a complete bypass of the security boundary separating distinct OAuth resource domains. Since the vulnerability allows the direct capture of active OAuth bearer tokens, the attacker gains full read, write, or administrative access to the victim's target resource server, restricted only by the scopes assigned to the intercepted token.

In the context of CVSS 3.1, this vulnerability results in a Scope Change (S:C). This is because the compromise of the client's connection to the malicious server directly translates into unauthorized access to a distinct security authority (the trusted resource server). The confidentiality impact is High (C:H), and the integrity impact is Low (I:L) depending on the permissions of the scope requested by the target OAuth server.

No availability impact (A:N) is directly linked to this token theft. The base score is assessed at 8.2 (High). Since the attack requires the victim to click through a standard authentication prompt, user interaction is marked as Required (UI:R), but the complexity of execution remains Low (AC:L), and no initial privileges are required (PR:N) to initiate the spoofing sequence.

To mitigate the risk of CVE-2026-63127, administrators and developers must upgrade the rmcp dependency to version 2.0.0 or higher. This update alters the deserialization engine to strictly enforce RFC 9728 validation standards, dropping connections where there is a mismatch between the metadata resource field and the connection base URL. Developers should adjust their Cargo.toml file to require version 2.0.0 or later and ensure that lockfiles are fully regenerated.

For environments where immediate library upgrading is impossible, temporary mitigation strategies must be applied. Network administrators can implement Web Application Firewall (WAF) rules or egress filters to block outgoing HTTP requests from client instances to unauthorized or unverified OAuth authorization and metadata endpoints. Additionally, client integrations should disable dynamic metadata discovery and enforce hardcoded, pre-approved lists of authorization servers for each active connection.

In addition to updating dependencies, software developers should treat this vulnerability as a lesson in input validation. Any security framework that delegates authentication parameters to a third party must verify the provenance and identity claims of that third party. Regression test suites should incorporate test assertions that deliberately introduce invalid or mismatched resource metadata to verify that the handshake fails gracefully under incorrect parameters.