RustSec logo

History ⋅ Edit ⋅ JSON (OSV)

RUSTSEC-2026-0457

OAuth client SSRF filter checks host strings, not resolved addresses

Reported
Issued
Package
rmcp (crates.io)
Type
Vulnerability
Keywords
#ssrf #oauth #mcp
Aliases
References
Patched
  • >=3.7.0
Unaffected
  • <2.0.0

Description

From 2.0.0 until 3.7.0, the rmcp OAuth client decided whether it may fetch an authorization server's metadata URL by inspecting only the host string. It rejected literal loopback, private and link-local IP addresses and known cloud metadata hostnames, but it did not resolve other hostnames. A hostname that resolves to an internal address passed the check.

A malicious MCP server can return protected-resource metadata that names an authorization server whose hostname resolves to an internal address. The client then sends GET requests to that address during discovery.

The same release fixes two related bypasses:

The impact is client-side SSRF. Responses are not returned to the attacker directly. Unauthenticated internal HTTP services are reachable. Cloud metadata endpoints that require headers or IMDSv2 are largely unaffected.

The flaw was corrected in 3.7.0. AuthorizationManager::new now builds its HTTP client with a DNS resolver that applies the address policy to every resolved address, and checks every IP-literal URL and followed redirect against the same policy. Loopback and private addresses are allowed only when the MCP server's own URL names one of that class. Deployments that reach their authorization server through a hostname that resolves to a private address should use AuthorizationManager::new_allowing_private_addresses.

Clients supplied through new_with_oauth_http_client are not covered by the resolved-address checks. Such clients must enforce their own outbound address policy.

Advisory available under CC0-1.0 license.