mcp-remote EUVD-2026-86017

Requires the victim to be running mcp-remote 0.1.32 through 0.1.38 and to initiate a connection (via the OAuth discovery/authentication flow) to a remote MCP server that the attacker controls or has compromised; that server returns a WWW-Authenticate header whose resource_metadata URL points at an internal or metadata endpoint, which mcp-remote then fetches without URL validation. Limiting factors: the attacker must control the MCP server endpoint the client connects to (so the victim must be induced to trust a malicious/compromised server), and impact is bounded to what the client host can reach on its internal network - meaning realistic risk is highest in cloud/container hosts where SSRF reaches instance-metadata services.

Signals conflict sharply on this one. NVD assigns CVSS 9.1 (Critical) with AV:N/AC:L/PR:N/UI:N and both C:H and I:H, but EPSS is only 0.17% (5th percentile), there is no CISA KEV listing, and no weaponized public exploit is identified - only a third-party research advisory (playb0t/mcp-remote-oauth-security F-01) and the vendor GHSA describing the flaw. The 9.1 score appears overstated: this is a client-side SSRF where mcp-remote fetches the resource_metadata URL from a remote server's WWW-Authenticate header, so integrity impact (I:H) is questionable (a blind/GET-style metadata fetch confers little integrity change), and UI:N is debatable because exploitation requires the victim to point mcp-remote at an attacker-controlled or compromised MCP server. Realistically this is a MEDIUM-severity, targeted issue (attacker must lure the client to a malicious server), not a mass-exploitable internet-facing critical. It is a genuine SSRF worth patching for anyone running the affected 0.1.32-0.1.38 range - especially in cloud environments where SSRF reaches instance-metadata endpoints - but the low EPSS and absence of KEV/POC indicate it is not currently a widespread exploitation priority. Note: CPE is a placeholder (cpe:2.3:a:n/a:n/a) and affected-version data in EUVD is 'n/a', so version scoping relies solely on the CVE description text - verify against the vendor advisory.

An attacker stands up (or compromises) a remote MCP server and induces a victim to connect their mcp-remote client to it. During the OAuth discovery flow the malicious server returns a WWW-Authenticate header whose resource_metadata URL points at an internal address (e.g. cloud metadata at 169.254.169.254 or an internal admin service); mcp-remote fetches it without validation, performing requests from inside the victim's trust boundary. No public weaponized exploit is identified, though a detailed third-party advisory documents the mechanics.