Summary
A server-side request forgery vulnerability in mcp-remote allows a remote MCP server to influence the resource_metadata URL obtained from its WWW-Authenticate header. When that URL is fetched without sufficient destination validation, an attacker may cause requests to internal services or other unintended network locations.
Affected context
The vulnerability occurs in mcp-remote deployments that process authentication challenges from remote MCP servers and extract a resource_metadata URL from the WWW-Authenticate header. Risk is present when the resulting URL is requested by the mcp-remote process without adequately restricting destinations, protocols, redirects, or access to private network resources.
Exploit preconditions
- Attack surface: Processing of WWW-Authenticate headers received from a remote MCP server
- Required access: Ability to cause a victim mcp-remote client to connect to, or authenticate against, an attacker-influenced MCP server
- Trigger point: Extraction and retrieval of the resource_metadata URL
- Why exploitation is possible: The server-controlled URL may be used to initiate outbound requests without sufficient validation of its destination or network location
Why this happens
The underlying bug is server-side request forgery caused by trusting a URL supplied through a remote server's authentication metadata. This maps to CWE-918: Server-Side Request Forgery, where application-controlled network functionality can be redirected to attacker-selected destinations, potentially including services that are not directly reachable by the attacker.
Potential impact
- Requests to internal services or cloud metadata endpoints may be initiated
- Sensitive response data may be exposed if responses are returned or processed
- Internal administrative interfaces could be probed
- Network-based access controls may be bypassed
- Follow-on compromise could occur if reachable services accept or act on the requests
General mitigation guidance
Mitigation generally focuses on treating resource metadata URLs as untrusted network destinations and reducing the privileges of outbound requests.
Common defensive patterns include:
- Allowing only approved URL schemes, hosts, ports, and redirect targets
- Blocking loopback, link-local, private, and other restricted address ranges
- Resolving hostnames safely and rechecking destinations after redirects
- Applying outbound network policies and egress allowlists
- Avoiding unnecessary retrieval of remote metadata and limiting returned data
- Running clients with least-privilege network and filesystem permissions
- Separating metadata retrieval from sensitive internal networks where possible
How teams detect issues like this
Organizations can look for SSRF risks through:
- Static analysis of code that fetches URLs derived from HTTP headers or remote responses
- Code review signals involving unrestricted HTTP clients, redirect following, or missing private-address checks
- Tests covering loopback, private, link-local, metadata-service, alternate-encoding, and redirect destinations
- Egress monitoring for unusual requests from mcp-remote processes
- Network policy enforcement that restricts outbound traffic to approved destinations
- Automated security review tools that flag user- or server-controlled URL construction
