rmcp OAuth client fetches attacker-chosen URLs, advisory warns

A security advisory published on 2 October 2026 says the OAuth client in rmcp, the Rust software development kit for the Model Context Protocol, can be tricked into sending requests to internal addresses chosen by the server it connects to.

According to advisory GHSA-c9xm-49cp-xcr9, the problem is in how the client handles the WWW-Authenticate header that servers return with an HTTP 401 response. That header can include a resource_metadata= value, which is meant to point the client at a document describing the protected resource. The advisory says rmcp parses that value as a URL and then fetches it with no check that it belongs to the same server, and no check on the scheme, host, DNS result or IP range.

That makes it a server-side request forgery, or SSRF, where an attacker gets a victim's software to make network requests on its behalf. The advisory says a malicious or compromised MCP server can return a header such as Bearer resource_metadata="http://169.254.169.254/latest/meta-data/" and the client will issue an outbound GET to that address from the victim application's own network position.

The advisory lists cloud metadata endpoints, services bound only to localhost, private virtual private cloud or container-network services, and internal HTTP APIs as potential targets. It also says that where the target returns JSON matching the expected metadata shape, the flow can chain into further authorisation-server metadata fetches. The only requirement on the victim, according to the advisory, is that its client connects to a server able to emit the crafted header.

The advisory frames severity as high or medium, depending on where the embedding application sits on the network and whether the response handling tells the attacker anything useful about success or failure.

The affected code is in crates/rmcp/src/transport/auth.rs in the modelcontextprotocol/rust-sdk repository. The advisory says the reviewed main commit was c330fede90e4729c234f8e87fdbc5ea27a1dd10c, dated 19 May 2026. Two functions are named in the report: extract_www_authenticate_params(), which accepts the absolute URL from the header, and fetch_resource_metadata_from_url(), which performs the GET.

The report suggests requiring the metadata URL to be same-origin with the original MCP server URL, unless the specification deliberately allows a narrow exception. It also recommends rejecting loopback, link-local, RFC 1918 and unique-local IPv6 addresses along with known cloud metadata hostnames, rejecting non-HTTP and non-HTTPS schemes, and applying the same checks to redirect targets and any follow-on metadata URLs. A short same-origin comparison of scheme, host and effective port is included as a minimal fix. Where cross-origin metadata is needed for compatibility, the advisory says it should be an explicit opt-in with private-network blocking still in place.

The reporter also documented a duplicate check carried out on 27 May 2026. At that point the visible repository advisories were GHSA-9g45-5xwm-f3wc, covering custom HTTP headers leaking to cross-origin redirect targets, and GHSA-89vp-x53w-74fx, covering DNS rebinding in the Streamable HTTP server transport. Searches for WWW-Authenticate resource_metadata SSRF returned no matches, and a search for resource_metadata returned one closed issue about authorisation discovery fallback rather than resource validation. The advisory says the issue is distinct from both existing advisories. Its status is recorded as reported.