CVE-2026-80347 in mcp-fetch
Summary
by MITRE • 08/26/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability in mcp-fetch represents a critical Server-Side Request Forgery (SSRF) flaw rooted in improper input sanitization and flawed logic within its security guard mechanisms. The core issue arises from how the application handles IPv6 literal addresses, specifically those enclosed in square brackets as per RFC 3986 standards for URIs containing hostnames that are IP literals. When a fetch target is provided with an IPv6 address such as http://[::1]/, the parsing logic extracts the hostname component including the surrounding brackets. This bracketed string is then passed to the net.isIP function for validation. However, standard implementations of net.isIP do not recognize bracket-enclosed strings as valid IP addresses and consequently return zero or false, indicating that the value is not a recognized IP format.
This incorrect classification triggers a fallback mechanism in the security logic. Because the initial check fails to identify the target as an IP address, the code skips the critical branch responsible for checking against private, reserved, or loopback address ranges. Instead of validating the actual numeric content within the brackets, the system attempts to resolve the bracketed string as a DNS hostname. Since strings like [::1] are not valid domain names and cannot be resolved by standard DNS infrastructure, the resolution process yields no addresses. In many security implementations, a failure to resolve or an empty result set is interpreted as a safe outcome because there is no active network connection established during this validation phase. Consequently, the guard erroneously classifies the malicious IPv6 literal as safe, allowing it to proceed to the actual HTTP client execution layer.
Once the flawed security check passes, the underlying HTTP client library processes the URL and automatically strips the square brackets before initiating the TCP connection. This stripping action reveals the true destination address, which is then used for network communication. As a result, an attacker can successfully direct internal requests to loopback interfaces or private IP ranges that were explicitly intended to be blocked by the SSRF guard. The vulnerability is further exacerbated by the handling of IPv4-mapped IPv6 addresses, denoted by the ::ffff: prefix. Even if the bracket stripping issue were mitigated, the existing logic for detecting private IPv6 addresses lacks specific case handling for this mapped format. This means that targets expressed in IPv4-mapped IPv6 notation would also bypass security checks and reach internal services, including sensitive link-local metadata endpoints often used by cloud providers to expose instance configuration data.
The operational impact of this vulnerability is severe due to the context in which mcp-fetch operates as a tool argument for an AI model. An attacker who can influence or manipulate the inputs provided to the language model can exploit this flaw to force the application to make HTTP requests to internal network resources that are normally inaccessible from external networks. By crafting specific fetch targets, an adversary can read responses from internal APIs, database endpoints, or cloud metadata services back into the model's context window. This not only violates the principle of least privilege and network segmentation but also enables data exfiltration of sensitive internal information through the AI interface.
From a classification perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF), specifically involving improper restriction of actions performed by an authenticated user on behalf of another system or service. It also relates to CWE-20 Improper Input Validation, as the application fails to correctly parse and validate IP literals according to standard URI specifications. In terms of offensive security frameworks, this exploit maps directly to MITRE ATT&CK technique T1598 Phishing for Information, where an attacker uses social engineering or input manipulation via a trusted interface (the AI model) to harvest internal network data.
To mitigate this vulnerability, immediate remediation is required in the URL parsing and validation logic of mcp-fetch. Developers must ensure that IPv6 literals are correctly identified before any DNS resolution attempts occur. This involves stripping square brackets from IPv6 addresses prior to passing them to IP address verification functions like net.isIP or equivalent libraries. Furthermore, the private address checking logic must be updated to explicitly handle both standard IPv4/IPv6 ranges and their mapped counterparts, such as ::ffff:0:0/96 for IPv4-mapped addresses. Implementing a strict allowlist of permitted hostnames or IP ranges is recommended over relying solely on negative blocking lists, which are prone to bypasses via encoding tricks or protocol ambiguities. Additionally, enforcing network-level controls such as egress filtering can provide defense-in-depth by preventing the application from connecting to internal subnets regardless of how the request was constructed within the application logic.