RMCP OAuth Resource Confusion Enabling MCP Access Token Theft

Technical Analysis

The vulnerability lies in discover_oauth_server_via_resource_metadata in crates/rmcp/src/transport/auth.rs, which omits the RFC 9728 'resource' field check on ResourceServerMetadata and does not confirm the resource identifier returned by discovery matches the configured MCP server. A malicious MCP server acts as the entry point: it publishes protected-resource metadata pointing to a different, legitimate MCP resource and its authorization server. When a victim client connects to the malicious server and completes the OAuth authorization code flow, the resulting access token—valid for the legitimate resource—is sent to the malicious server instead, which can capture and replay it to impersonate the victim within the token's granted scopes. This crosses a trust boundary between MCP server identity and OAuth resource identity, effectively enabling a confused-deputy/token-relay attack across two distinct MCP servers.

Affected Systems

rmcp (Rust SDK for Model Context Protocol); protocols: MCP, OAuth 2.0, RFC 9728

Detection Signatures

• Log entries showing OAuth authorization completed against a resource server URI different from the originally configured MCP server endpoint
• Token issuance events where 'resource' claim/parameter does not match client-configured MCP server identity
• Unexpected redirects to unfamiliar or newly-registered authorization server domains during MCP client OAuth handshake
• Client connections to MCP servers whose protected-resource metadata lacks or mismatches the RFC 9728 'resource' field
• Repeated OAuth flows initiated by the same client toward multiple distinct MCP resource identifiers in short succession

Remediation Steps

1. 1

   Upgrade rmcp to 2.0.0 or later

   Apply the patched release that enforces resource identifier validation per RFC 9728 during OAuth discovery.

2. 2

   Validate resource metadata strictly

   Ensure MCP clients confirm the 'resource' field in ResourceServerMetadata exactly matches the configured/expected MCP server before proceeding with authorization.

3. 3

   Scope and shorten token lifetimes

   Limit OAuth token scope and expiration for MCP access tokens to reduce the impact window if a token is captured.

4. 4

   Pin and allowlist MCP server endpoints

   Restrict clients to a known allowlist of trusted MCP server URIs and authorization servers rather than dynamically trusting discovered metadata.

5. 5

   Monitor for cross-resource token use

   Add server-side detection for access tokens being presented from unexpected client/server pairings or IP origins.