CVE-2026-79749: MCPHub: SSRF Guard Bypass via IPv6 Transition Addresses in URL Validation
MCPHub is a unified hub for centrally managing and dynamically orchestrating multiple MCP servers/APIs into separate endpoints with flexible routing strategies. Prior to version 1.0.32, MCPHub's SSRF guard in src/utils/ssrf.ts uses a custom isBlockedIpv6 function that only checks for loopback, link-local, unique-local, IPv4-mapped, and IPv4-compatible IPv6 addresses. IPv6 transition address families -- NAT64 (64:ff9b::/96), 6to4 (2002::/16), and Teredo (2001::/32) -- are not checked. An attacker who can specify a URL for an MCP server connection can encode a private IPv4 address inside one of these IPv6 forms to bypass the SSRF guard and reach internal infrastructure. This issue has been patched in version 1.0.32.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
MCPHubto a version that resolves this vulnerability.Fixed in 1.0.32
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker must be able to specify a URL used for an MCP server connection. They can use NAT64, 6to4, or Teredo IPv6 address forms to encode a private IPv4 destination and bypass the SSRF guard.
Which deployments are affected?
MCPHub versions prior to 1.0.32 are affected where users or other untrusted parties can provide MCP server connection URLs. The vulnerable validation does not block the listed IPv6 transition address families.
What should teams do if they cannot upgrade immediately?
Restrict who can create or modify MCP server connection URLs, and prevent MCPHub from reaching internal infrastructure through network egress controls. Treat NAT64 (64:ff9b::/96), 6to4 (2002::/16), and Teredo (2001::/32) destinations as potentially able to represent private IPv4 addresses.
How can I determine whether the issue is remediated?
Upgrade to MCPHub version 1.0.32 or later. Versions before 1.0.32 use the incomplete IPv6 SSRF validation described in the advisory.