highAgent ThreatTool Misuse

SSRF Filter Bypass via IPv4-Mapped IPv6 Loopback Normalization in auth-fetch-mcp

First seen Aug 13, 2026 · Updated Aug 13, 2026 · CVSS 7.4

SSRFMCPinput-validation-bypassIPv6loopbackIP-normalizationfetch-toolASI05 · Unsafe Code ExecutionAML.T0053Surface: Tool LayerPropagation: Single Hop

The auth-fetch-mcp server, which lets AI assistants fetch authenticated web content, has a flawed SSRF blocklist that fails to catch IPv4-mapped IPv6 loopback addresses in their hex-normalized form. An attacker who can influence the URL passed to the fetch tool (directly or via prompt injection) can reach internal loopback services that the security control was explicitly designed to block. This is exploitable out-of-the-box with no special configuration.

Technical Analysis

The `assertSafeUrl()` function in `src/security.ts` relies on `isPrivateV6()` to detect private/loopback IPv6 addresses before allowing the MCP fetch tool to make a request. When a URL like `http://[::ffff:127.0.0.1]:PORT/` is supplied, Node's WHATWG URL parser normalizes the host to its compressed hex form `[::ffff:7f00:1]`, and the check `net.isIPv4('7f00:1')` incorrectly returns false, causing the private-IP detection to be skipped entirely. This allows the underlying HTTP client or headless browser used by the MCP server to issue requests to loopback-bound services (e.g., internal admin panels, metadata endpoints, or other local agents/tools) that should have been blocked. Because MCP tool calls are often invoked autonomously based on LLM-generated arguments, a malicious or injected instruction could steer the agent to fetch such a crafted URL, turning an SSRF bug into a practical attack vector against the host running the agent.

Affected Systems

auth-fetch-mcp; protocols: MCP

Detection Signatures

  • URLs containing IPv6 literal hosts with the ::ffff: prefix, especially variants of [::ffff:127.0.0.1] or other loopback/private ranges in mapped-IPv6 hex form
  • Outbound requests from the MCP fetch tool targeting loopback or link-local addresses
  • Log entries where assertSafeUrl()/isPrivateV6() allows a request despite a private-looking host
  • Unexpected fetch tool calls to ports commonly used by internal services (e.g., 22, 3306, 6379, 8080, 169.254.169.254 equivalents)

Remediation Steps

  1. 1

    Upgrade auth-fetch-mcp

    Update to version 3.0.1 or later, which patches the isPrivateV6() normalization bug.

  2. 2

    Use a robust IP-classification library

    Replace manual regex/string-based IPv6 checks with a well-tested IP address parsing library that fully normalizes and canonicalizes addresses (including IPv4-mapped and IPv4-compatible IPv6 forms) before classification.

  3. 3

    Apply defense-in-depth network controls

    Enforce SSRF protections at the network layer (egress filtering, firewall rules blocking loopback/link-local/metadata ranges) rather than relying solely on application-level checks.

  4. 4

    Sanitize and constrain LLM-supplied URLs

    Validate and constrain the set of URLs an agent can request via allowlists, and treat any LLM-provided URL as untrusted input requiring re-validation post-DNS/host resolution.

  5. 5

    Monitor and audit outbound MCP tool requests

    Log and alert on fetch tool requests targeting internal, loopback, or unusual IP ranges to detect exploitation attempts.

CVE / Advisory IDs

CVE-2026-49857

Industries Most Exposed

TechnologySaaSCloud InfrastructureFinancial ServicesAny organization deploying AI agents with authenticated web-fetch tooling

Sources

Respond to this threat

Pro subscribers get a full AI-generated incident-response playbook for this threat — detection, containment, eradication, and recovery steps — plus an unlimited AI Threat Advisor for questions about your environment.