CVE-2026-63127: RMCP: Missing Resource Field Validation in OAuth Protected Resource Metadata Discovery

Summary

The rmcp library does not validate the resource parameter in OAuth Protected Resource metadata (RFC 9728), allowing a malicious MCP server to redirect OAuth flows to a legitimate authorization server and steal the resulting access tokens.

Details

RFC 9728 specifies two MUST requirements for resource parameter validation:

• Section 7.3: the client MUST ensure that the resource identifier URL it is using as the prefix for the metadata request exactly matches the resource value in the returned metadata document.
• Section 3.3: if the resource value returned is not identical to the URL the client used, the data MUST NOT be used.

In the current implementation (crates/rmcp/src/transport/auth.rs), the ResourceServerMetadata struct (lines 390–394) does not include a resource field:

struct ResourceServerMetadata {
    authorization_server: Option<String>,
    authorization_servers: Option<Vec<String>>,
    scopes_supported: Option<Vec<String>>,
}

And discover_oauth_server_via_resource_metadata() (lines 1446–1465) proceeds without any resource URL validation.

Recommended fix

1. Add the resource field to the struct: ``rust struct ResourceServerMetadata { resource: Option<String>, // RFC 9728 REQUIRED field authorization_server: Option<String>, authorization_servers: Option<Vec<String>>, scopes_supported: Option<Vec<String>>, } ``
2. Add validation logic after fetching metadata: ```rust let Some(resource_metadata) = self .fetch_resource_metadata_from_url(&resource_metadata_url) .await? else { return Ok(None); };

// RFC 9728: validate that the resource identifier matches our target server if let Some(resource) = &resource_metadata.resource { if resource.trim_end_matches('/') != self.base_url.as_str().trim_end_matches('/') { return Err(AuthError::MetadataError(format!( "Resource metadata mismatch: expected '{}', got '{}'", self.base_url, resource ))); } }

### PoC

1. Attacker sets up a malicious MCP server at `fake-mcp.com/mcp`. 
2. At `fake-mcp.com/mcp/.well-known/oauth-protected-resource`, the attacker serves metadata declaring:
    - resource: `real-mcp.com/mcp` (the legitimate server)
    - authorization_servers: the legitimate authorization server(s) of `real-mcp.com/mcp`


3. Victim configures any MCP client using `rmcp` to connect to `fake-mcp.com/mcp`.

4. `rmcp` fetches the protected resource metadata and, without validating that the `resource` field (`real-mcp.com/mcp`) differs from the configured server (`fake-mcp.com/mcp`), initiates an OAuth flow with the legitimate authorization server.
5. The victim sees a legitimate authorization prompt and completes the flow.
6. The resulting access token — valid for `real-mcp.com/mcp` — is sent to `fake-mcp.com/mcp` in subsequent requests.
7. The attacker captures the token and can impersonate the victim on `real-mcp.com/mcp`.

### Impact
This is an access token theft vulnerability via OAuth resource metadata spoofing. All MCP clients built on `rmcp` that rely on OAuth-protected MCP servers are affected. An attacker who tricks a user into connecting to a malicious MCP server can steal valid access tokens for any legitimate MCP server, enabling full impersonation of the victim.

#### Credit
Jian Cui, Minsun Shim, Zhou Li, Xiaojing Liao
University of Illinois Urbana-Champaign (UIUC)
University of California, Irvine (UCI)