Rust MCP library flaw lets rogue servers steal OAuth tokens

A security advisory published on 16 September 2026 says the Rust rmcp library, used to build Model Context Protocol clients, fails to validate a required field during OAuth discovery, allowing a malicious MCP server to steal access tokens issued for a legitimate one. The flaw is tracked as CVE-2026-63127 under GitHub advisory GHSA-33f5-2c5q-wgwj.

According to the advisory, the problem sits in the library's handling of OAuth Protected Resource metadata, defined in RFC 9728. That standard sets out two mandatory checks: a client must confirm that the resource identifier URL it used as the prefix for its metadata request exactly matches the resource value returned in the metadata document, and it must not use the data if the two differ.

The advisory states that rmcp does neither. In the file crates/rmcp/src/transport/auth.rs, the ResourceServerMetadata struct does not even include a resource field, capturing only the authorization server details and supported scopes. The discovery function that fetches the metadata then proceeds without any resource URL validation.

The practical consequence, as described in the advisory's proof of concept, is straightforward. An attacker stands up a malicious MCP server — a server that exposes tools and data to an AI agent — at a domain they control. At that domain's well-known OAuth protected resource endpoint, they publish metadata that declares the resource to be a legitimate MCP server, and lists that legitimate server's real authorization servers.

A victim who configures any rmcp-based client to connect to the attacker's server will see the client fetch that metadata and begin an OAuth flow against the genuine authorisation server. The user is shown a legitimate-looking authorisation prompt and completes it. The resulting access token is valid for the real server, but the client then sends it to the attacker's server in subsequent requests. The advisory says the attacker can capture that token and impersonate the victim on the legitimate service.

The advisory describes the impact as access token theft via OAuth resource metadata spoofing, and says all MCP clients built on rmcp that rely on OAuth-protected MCP servers are affected. Full impersonation of the victim is possible, it says.

The recommended fix set out in the advisory is to add the resource field to the metadata struct, marked as a required field under RFC 9728, and to compare it against the client's configured base URL after fetching the document. The suggested code trims trailing slashes from both values before comparison and returns a metadata error when they do not match, rather than continuing with the OAuth flow.

The advisory credits the finding to Jian Cui, Minsun Shim, Zhou Li and Xiaojing Liao, of the University of Illinois Urbana-Champaign and the University of California, Irvine.

The pattern is a familiar one in agent tooling: a client follows a pointer supplied by an untrusted server and treats the answer as authoritative. In this case the specification anticipated the problem and wrote the defence into the standard as a hard requirement, but the implementation left it out. The advisory does not state a fixed version.