GHSA-5p52-q7pq-9fq2

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:

• Bracketed IPv6 literals such as http://[::1]:6379/ were not recognized as internal, because the check kept the brackets from the URL host.
• token_endpoint and registration_endpoint from authorization server metadata were not checked at all, and token requests follow redirects. A malicious authorization server could make the client send POST requests to an internal address.

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.