rmcp's OAuth client accepts a resource identifier it never checks, letting a hostile MCP server hand you a token for someone else's server

NVD·high signalXBlueskyLinkedInCopy link

CVE-2026-63127 (8.2 HIGH, published 2026-09-16) covers rmcp's `crates/rmcp/src/transport/auth.rs` omitting the RFC 9728 `resource` field from `ResourceServerMetadata` and letting `discover_oauth_server_via_resource_metadata` use protected-resource metadata without confirming the returned resource identifier matches the configured MCP server. A malicious server can publish metadata for a different legitimate MCP resource, so a victim completing the flow ends up with a token minted for that other resource. A companion advisory, GHSA-c9xm-49cp-xcr9, covers the same file fetching an attacker-supplied `resource_metadata=` URL from `WWW-Authenticate` with no same-origin or private-network check, an SSRF reaching localhost, RFC 1918 space and cloud metadata endpoints. Both patched in rmcp 2.0.0.