Description

mcp-fetch checks a fetch target against its SSRF guard without removing the brackets that surround an IPv6 literal. isSafeUrl reads the hostname from the parsed URL, which for a literal such as http://[::1]/ yields the bracketed string, and then tests it with net.isIP. That call returns zero for a bracketed value, so the branch holding the private-address checks is skipped entirely. The guard falls back to resolving the hostname, the bracketed string is not a resolvable name, no addresses are returned, and the target is reported safe. The HTTP client then strips the brackets and connects. Because the address may be given in IPv4-mapped form, the same path reaches any IPv4 target the loopback and private checks were meant to exclude, including link-local metadata endpoints. isPrivateIPv6 also has no case for the ::ffff: prefix, so the mapped form would still pass even if the brackets were removed. The fetch target is supplied as a tool argument, so an attacker who can influence what the model requests can read internal responses back into the model context.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-26T10:16:42.803Z",
  "pubdate": "2026-08-26T10:16:42.803Z",
  "executiveSummary": "A Server-Side Request Forgery (SSRF) vulnerability exists in mcp-fetch due to improper sanitization of IPv6 literal addresses. The security guard fails to strip square brackets from IPv6 hostnames before validation, causing the application to incorrectly evaluate the safety of the request target.\nThe vulnerability allows an attacker who can influence the fetch target argument to bypass built-in SSRF protections, including loopback and private network address restrictions. By crafting a request using a bracketed IPv6 literal or an IPv4-mapped IPv6 address (e.g., ::ffff:127.0.0.1), an attacker can force the system to perform unauthorized requests to internal infrastructure, such as metadata endpoints or services bound to localhost.\nThis flaw is particularly critical in contexts where an LLM or model is used to facilitate tool calls, as it provides a mechanism for unauthorized data exfiltration or internal service interaction. The risk is compounded by the fact that the underlying HTTP client correctly processes the bracketed input after the security guard has been bypassed, rendering the check ineffective against both IPv6 and IPv4-mapped IPv6 payloads.",
  "technicalDetails": "The root cause of the vulnerability lies in the implementation of the SSRF guard within mcp-fetch, specifically how it processes IPv6 literal hostnames. When a URL such as http://[::1]/ is provided, the function isSafeUrl parses the hostname and retains the surrounding square brackets. Subsequent security validation logic utilizes net.isIP to verify the address's safety. However, net.isIP returns zero (indicating failure) when provided with a bracketed string because it does not recognize the syntax.\nDue to this validation failure, the security logic skips the critical branch responsible for private-address and loopback checking. The guard then falls back to hostname resolution. Since the bracketed string is not a valid resolvable DNS hostname, the resolution process returns no addresses, leading the guard to conclude the target is safe. Once the security check is bypassed, the downstream HTTP client receives the original URL, strips the brackets, and establishes a connection to the intended target.\nExploitation is trivial for an attacker capable of supplying arbitrary URLs to the mcp-fetch tool. By providing an IPv4-mapped IPv6 address, such as [::ffff:169.254.169.254], an attacker can bypass the filters designed to block RFC1918 and link-local address spaces. The isPrivateIPv6 validation logic further fails to account for the ::ffff: prefix, ensuring that these mapped addresses are treated as safe regardless of the underlying target. The attack flow follows these steps: 1) The attacker inputs a crafted bracketed IPv6 or IPv4-mapped IPv6 URL into the mcp-fetch tool argument. 2) The SSRF guard executes isSafeUrl, which fails to correctly identify the bracketed IP as a restricted address, resulting in an erroneous 'safe' classification. 3) The HTTP client strips the brackets and resolves or connects to the internal destination. 4) The service processes the request and returns the internal data, which is subsequently exposed to the model context, allowing the attacker to read responses from restricted internal network services."
}