The rmcp OAuth client parses the resource_metadata URL from the WWW-Authenticate header without validating that the URL is same-origin or blocking loopback, link-local, RFC 1918, or cloud metadata addresses. It then performs an HTTP GET request to that URL from the victim application's network context. This behavior enables server-side request forgery (SSRF) attacks where an attacker-controlled MCP server can cause the client to access internal services or cloud metadata endpoints. The vulnerability affects versions of the rmcp crate prior to 2.0.0. The recommended fix is to enforce same-origin validation and block private network and cloud metadata addresses before fetching the resource_metadata URL.

This vulnerability allows an attacker who controls or compromises the MCP server to induce the victim client to make HTTP requests to internal network resources, including localhost, private IP ranges, and cloud metadata endpoints. This can lead to unauthorized information disclosure or further chained metadata fetches if the internal endpoints return expected JSON structures. The impact depends on the network position of the client and the sensitivity of the internal services accessible via SSRF.

A patch is available to address this vulnerability. The fix involves validating that the resource_metadata URL is same-origin with the MCP server URL and rejecting URLs that point to loopback, link-local, RFC 1918, unique-local IPv6, or known cloud metadata hostnames. Non-HTTP(S) schemes should also be rejected. These validations should apply to redirect targets and any subsequent metadata URLs. Users should update to a patched version of the rmcp crate to mitigate this SSRF risk.