Description

The proxy middleware in mcp-use's inspector forwards requests to a destination the caller names. mountMcpProxy in libraries/typescript/packages/inspector/src/server/proxy/mcp-proxy.ts read the target from the X-Target-URL header or the __mcp_target parameter and proxied to it without inspecting the host, so loopback, link-local and private addresses were all accepted, as were names that resolve to them, and the validation was not reapplied to a redirect the destination returned. A caller could therefore make the server issue requests to addresses reachable only from the host it runs on and read the responses. The current code calls isSafeProxyTarget, which checks the resolved address against private, loopback and link-local ranges before proxying and bounds the number of redirects followed.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.6",
  "pubDate": "2026-08-27T17:20:51.183Z",
  "pubdate": "2026-08-27T17:20:51.183Z",
  "executiveSummary": "A Server-Side Request Forgery (SSRF) vulnerability exists within the proxy middleware of the mcp-use inspector component. The vulnerability arises from improper validation of user-supplied destination addresses during proxy operations, allowing unauthenticated remote attackers to force the server to initiate arbitrary network requests.\nThe flaw allows an attacker to interact with internal resources, including those residing on loopback interfaces, link-local addresses, and private subnets, effectively bypassing network perimeters. By leveraging the server's identity to query internal services, an attacker could exfiltrate sensitive configuration data, interact with protected management interfaces, or perform reconnaissance on the local network infrastructure.\nThe risk is critical as it enables cross-boundary data access that would otherwise be restricted by network security policies. Exploitation requires only the ability to supply a malicious URL to the proxy middleware via specific headers or parameters. While the vulnerability has been addressed through the implementation of address validation logic, deployments that do not strictly sanitize proxy targets remain exposed to unauthorized internal resource access.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the mountMcpProxy function located in libraries/typescript/packages/inspector/src/server/proxy/mcp-proxy.ts. The proxy middleware was designed to interpret the destination address from either the 'X-Target-URL' header or the '__mcp_target' query parameter. During the initial implementation, the proxy lacked sufficient validation logic to verify the target host, failing to restrict connections to internal network segments, specifically loopback (127.0.0.0/8), link-local (169.254.0.0/16), and RFC 1918 private address spaces.\nFurthermore, the vulnerability was exacerbated by a failure in redirect handling; even if initial validation were present, the proxy did not re-verify the destination after following HTTP redirects provided by the initial target server. This permitted an attacker to craft a payload that targets a public-facing server under their control, which subsequently responds with a 3xx redirect to an internal, sensitive resource, effectively bypassing any superficial domain-based filtering.\nThe attack flow follows a predictable pattern: 1) The attacker initiates a request to the mcp-use inspector server. 2) The attacker injects a target IP or hostname (e.g., 'http://127.0.0.1:8080' or a DNS name resolving to an internal resource) into the 'X-Target-URL' header. 3) The mountMcpProxy function accepts this input and initiates an outbound connection from the host server. 4) The proxy blindly performs the request and relays the response back to the attacker. 5) By chaining this with redirect primitives, the attacker can probe services that are restricted to local host access, such as metadata services or internal management APIs.\nPost-exploitation impact includes the potential for full server-side request execution within the local environment. An attacker can map the internal network topology, identify active services, and perform read-only operations on sensitive endpoints that do not require additional authentication headers if they are implicitly trusted by the host environment. The current remediation involves the introduction of the isSafeProxyTarget function, which proactively checks the resolved IP address of the target against restricted ranges and enforces a strict limit on the maximum number of redirects allowed to prevent infinite loops and redirect-based bypasses."
}