MCPHub IPv6 Transition Address SSRF Bypass

Technical Analysis

MCPHub's isBlockedIpv6 function in src/utils/ssrf.ts implements a denylist that only checks loopback, link-local, unique-local, and IPv4-mapped/compatible IPv6 forms, omitting the well-known IPv6 transition prefixes NAT64 (64:ff9b::/96), 6to4 (2002::/16), and Teredo (2001::/32). An attacker who controls or influences the URL used to configure an MCP server endpoint can encode a blocked private IPv4 address (e.g., 127.0.0.1 or 169.254.169.254) inside one of these transition formats so the string passes the IPv6 denylist check, but the underlying network stack or downstream resolver still routes the connection to the internal/private target. This crosses the trust boundary between the MCPHub orchestration layer and internal infrastructure it was meant to isolate from user-supplied MCP server URLs, potentially exposing internal services, cloud metadata endpoints, or other MCP servers not meant to be reachable externally. The impact is amplified because MCPHub acts as a routing hub for multiple MCP servers, so a successful SSRF could pivot into lateral access across the orchestrated agent/tool ecosystem.

Affected Systems

MCPHub; protocols: MCP

Detection Signatures

• Outbound requests from MCPHub containing IPv6 literals matching 64:ff9b::/96, 2002::/16, or 2001:0::/32 prefixes
• MCP server URL configuration values containing embedded IPv4 addresses encoded in IPv6 transition notation
• Unexpected connections from MCPHub host to RFC1918 ranges, 127.0.0.0/8, or 169.254.169.254 following IPv6-formatted server URL registration
• Log entries showing SSRF guard pass followed by connection to internal-only IP ranges

Remediation Steps

1. 1

   Upgrade MCPHub

   Update to MCPHub version 1.0.32 or later, which patches the SSRF guard to cover NAT64, 6to4, and Teredo transition address ranges.

2. 2

   Harden SSRF filtering

   Implement SSRF protection using a robust, actively maintained library that resolves and normalizes all IPv6 representations (including embedded/mapped IPv4) before applying denylist checks, rather than relying on custom regex/string-based detection.

3. 3

   Network-level egress controls

   Enforce network segmentation and egress filtering so the MCPHub host cannot reach internal-only ranges or cloud metadata endpoints regardless of application-layer filtering gaps.

4. 4

   Validate at resolution time, not string time

   Perform SSRF checks after DNS/address resolution and immediately before the outbound connection is made, to prevent TOCTOU-style filter bypasses via alternate address encodings.

5. 5

   Restrict MCP server URL sources

   Limit who can register or modify MCP server endpoint URLs in MCPHub to trusted administrators, and audit any user- or agent-supplied URLs before use.