CVE-2026-63127: 
Model Context Protocol Analyse et atténuation des vulnérabilités

CVE-2026-63127 is an OAuth resource metadata spoofing vulnerability in the RMCP Rust SDK (the official Rust SDK for the Model Context Protocol) that allows a malicious MCP server to steal valid OAuth access tokens from victims. Affected versions are all releases up to and including 1.8.0 (i.e., < 2.0.0). The vulnerability was discovered by researchers at the University of Illinois Urbana-Champaign (UIUC) and the University of California, Irvine (UCI), disclosed via a GitHub Security Advisory on June 29, 2026, and patched in rmcp v2.0.0 released the same day. It carries a CVSS v3.1 base score of 8.2 (High) (GitHub Advisory, Red Hat CVE).

The root cause is a logic flaw (CWE-345: Insufficient Verification of Data Authenticity; CWE-289: Authentication Bypass by Alternate Name) in crates/rmcp/src/transport/auth.rs. The ResourceServerMetadata struct (lines 390–394 in the pre-fix code) entirely omits the resource field mandated by RFC 9728, and the discover_oauth_server_via_resource_metadata() function proceeds to trust the returned metadata without verifying that the resource identifier in the metadata matches the URL of the MCP server the client is actually connecting to. RFC 9728 Sections 3.3 and 7.3 both impose MUST-level requirements for this exact check. An attacker operating a malicious MCP server can serve a /.well-known/oauth-protected-resource document that claims to represent a different, legitimate MCP server and points to that server's real authorization server, causing the victim's rmcp client to initiate a legitimate OAuth flow and then deliver the resulting access token to the attacker's server (GitHub Advisory, Fix PR #937).

Successful exploitation results in access token theft, enabling the attacker to fully impersonate the victim against any legitimate MCP resource for which the stolen token was issued, within all scopes granted during the authorization flow. The confidentiality impact is high (token and associated data exposure), integrity impact is low (attacker can make authorized requests as the victim), and there is no direct availability impact. All MCP clients built on rmcp versions prior to 2.0.0 that use OAuth-protected MCP servers are affected, and the stolen token can be chained into further attacks such as data exfiltration, privilege escalation (if the victim holds elevated scopes), or lateral movement within the MCP ecosystem (GitHub Advisory, Feedly).

A detailed proof-of-concept attack sequence (steps 1–7) is publicly documented in the GitHub Security Advisory, describing exactly how an attacker sets up a malicious MCP server to capture OAuth tokens (GitHub Advisory). No authentication is required on the attacker's side; user interaction (victim connecting to the malicious server and completing an OAuth flow) is required. The EPSS score is 0.0 and there is no evidence of in-the-wild exploitation at this time. The vulnerability is not currently listed in the CISA KEV catalog. NVD SSVC classifies exploitation status as "poc" and the attack as non-automatable (Feedly).

1. Set up malicious server: Attacker hosts a malicious MCP server at fake-mcp.com/mcp, accessible at the standard well-known endpoint fake-mcp.com/mcp/.well-known/oauth-protected-resource.
2. Serve spoofed metadata: The attacker's metadata endpoint returns a JSON document declaring resource: real-mcp.com/mcp (the legitimate target server) and authorization_servers pointing to the legitimate authorization server(s) of real-mcp.com/mcp.
3. Trick victim into connecting: Attacker social-engineers or otherwise causes the victim to configure their rmcp-based MCP client to connect to fake-mcp.com/mcp.
4. Client fetches metadata without validation: The rmcp client calls discover_oauth_server_via_resource_metadata(), retrieves the spoofed metadata from fake-mcp.com/mcp/.well-known/oauth-protected-resource, and — because ResourceServerMetadata lacks a resource field and no validation logic exists — accepts the metadata without checking that real-mcp.com/mcp matches fake-mcp.com/mcp.
5. OAuth flow initiated with legitimate server: The client extracts authorization_servers from the metadata and directs the victim to authenticate with the real, trusted authorization server for real-mcp.com/mcp.
6. Victim completes authorization: The victim sees a legitimate authorization prompt from the real authorization server, recognizes it as trustworthy, and grants consent.
7. Token delivered to attacker: The resulting access token — valid for real-mcp.com/mcp — is returned to the rmcp client, which then sends it in subsequent MCP requests to fake-mcp.com/mcp.
8. Attacker captures and replays token: The attacker captures the token from incoming requests to their server and replays it against real-mcp.com/mcp to impersonate the victim with all granted scopes (GitHub Advisory).

• Network: Unexpected OAuth authorization flows initiated toward a legitimate MCP authorization server when the client is configured to connect to an unfamiliar or newly added MCP server URL; outbound HTTP requests from the rmcp client to a /.well-known/oauth-protected-resource endpoint on an untrusted host.
• Logs: rmcp client logs showing successful metadata discovery from a server URL that does not match the resource field in the returned metadata (pre-patch behavior would not log this mismatch; post-patch logs will emit MetadataError: Protected resource metadata resource mismatch or missing required resource field).
• Application Behavior: Access tokens for a known legitimate MCP resource (real-mcp.com/mcp) being transmitted to a different, unexpected server URL; OAuth consent prompts appearing for a legitimate service when the user believes they are connecting to a different MCP endpoint.
• File System / Configuration: MCP client configuration files referencing unfamiliar or recently added MCP server URLs that were not explicitly provisioned by the organization (GitHub Advisory).

Upgrade the rmcp crate to version 2.0.0 or later, which adds the resource field to ResourceServerMetadata and enforces RFC 9728-compliant validation in discover_oauth_server_via_resource_metadata() — rejecting metadata where the resource field is missing or does not exactly match the configured MCP server URL (rmcp v2.0.0 Release, Fix PR #937). There is no known configuration-based workaround for versions prior to 2.0.0 — upgrading is the only remediation. Additionally, administrators should review any OAuth tokens that may have been issued through untrusted or unverified MCP servers and revoke them as a precaution (Red Hat CVE).

The vulnerability was credited to academic researchers Jian Cui, Minsun Shim, Zhou Li, and Xiaojing Liao from UIUC and UCI, indicating it was identified through security research rather than opportunistic discovery (GitHub Advisory). The fix was merged and released rapidly — the PR was merged on June 27, 2026, and the advisory published on June 29, 2026 — suggesting a coordinated disclosure process. Red Hat tracked the issue as a high-severity bug (Bug 2535503) in their security response system (Red Hat Bugzilla). No significant broader social media or media coverage has been identified at this time.