CVE-2026-79749: MCPHub SSRF Vulnerability via IPv6 Bypass

CVE-2026-79749 Overview

MCPHub is a unified hub for centrally managing and dynamically orchestrating multiple Model Context Protocol (MCP) servers and APIs into separate endpoints with flexible routing strategies. Versions prior to 1.0.32 contain a Server-Side Request Forgery (SSRF) flaw [CWE-918] in the SSRF guard implemented in src/utils/ssrf.ts. The custom isBlockedIpv6 function fails to check IPv6 transition address families, allowing attackers to reach internal infrastructure. Maintainers patched the issue in version 1.0.32.

Critical Impact
An authenticated attacker who supplies a URL for an MCP server connection can encode a private IPv4 address inside NAT64, 6to4, or Teredo IPv6 forms to bypass SSRF protections and pivot into internal networks.

Affected Products

MCPHub (samanhappy/mcphub) versions prior to 1.0.32
Deployments exposing MCP server connection URL configuration to untrusted users
Environments where MCPHub can reach internal or cloud-metadata endpoints

Discovery Timeline

2026-08-31 - CVE-2026-79749 published to the National Vulnerability Database
2026-08-31 - Last updated in NVD database

Technical Details for CVE-2026-79749

Vulnerability Analysis

MCPHub validates outbound URLs before initiating MCP server connections using an in-house SSRF guard located at src/utils/ssrf.ts. The isBlockedIpv6 helper enumerates a limited set of restricted IPv6 categories: loopback, link-local, unique-local, IPv4-mapped, and IPv4-compatible addresses. This allowlist-by-omission approach fails to account for IPv6 transition mechanisms that embed IPv4 addresses inside IPv6 packets.

An attacker supplies a URL such as http://[64:ff9b::7f00:1]/ to reach 127.0.0.1, http://[2002:a9fe:a9fe::]/ to hit the AWS metadata service at 169.254.169.254, or a Teredo-formatted address in 2001::/32. The guard treats these as public IPv6 destinations and permits the connection. MCPHub then performs the outbound request from its own network position.

Root Cause

The root cause is incomplete deny-list logic in isBlockedIpv6. NAT64 (64:ff9b::/96), 6to4 (2002::/16), and Teredo (2001::/32) address families were not enumerated. Each of these encodings can decode to an internal IPv4 destination, but the string comparison never inspects the embedded address. The check confirms only that the target is not one of the explicitly listed private ranges.

Attack Vector

Exploitation requires network access to MCPHub and low-privileged authenticated ability to define an MCP server connection URL. The attacker submits a crafted URL using an IPv6 transition prefix that embeds an internal IPv4 target. MCPHub resolves and connects to that address, exposing internal services, cloud metadata APIs, or administrative interfaces reachable from the host.

// Illustrative bypass targets (see advisory for details)
// NAT64 encoding of 127.0.0.1 → 64:ff9b::7f00:1
// 6to4 encoding of 169.254.169.254 → 2002:a9fe:a9fe::
// Teredo prefix range → 2001::/32

No verified public exploit code was published beyond the maintainer patch. See the GitHub Security Advisory GHSA-pr4x-3pc7-2fhw for the authoritative technical description.

Detection Methods for CVE-2026-79749

Indicators of Compromise

Outbound HTTP requests from the MCPHub host to internal RFC1918 addresses, 127.0.0.0/8, or link-local ranges such as 169.254.169.254.
MCP server configuration entries containing IPv6 literals with 64:ff9b::, 2002:, or 2001:0: prefixes.
Unexpected access log entries on internal services showing the MCPHub host as the source.

Detection Strategies

Inspect MCPHub configuration and audit logs for user-supplied MCP server URLs containing IPv6 transition prefixes.
Correlate egress network telemetry with MCPHub process activity to identify requests targeting metadata or internal management endpoints.
Deploy application-layer proxies that resolve hostnames and reject requests whose final destination decodes to a private IPv4 address.

Monitoring Recommendations

Alert on any MCPHub outbound traffic to cloud metadata endpoints, including 169.254.169.254 and fd00:ec2::254.
Monitor MCPHub version banners across the fleet and flag hosts running versions below 1.0.32.
Log all MCP server registration and edit events, including the requesting principal and submitted URL.

How to Mitigate CVE-2026-79749

Immediate Actions Required

Upgrade MCPHub to version 1.0.32 or later, published in the GitHub Release v1.0.32.
Restrict who can create or modify MCP server connection entries to trusted administrators only.
Place MCPHub in a network segment with egress filtering that blocks access to internal management and metadata addresses.

Patch Information

The fix is delivered in MCPHub 1.0.32. Review the code changes in the GitHub Commit Reference and the associated GitHub Pull Request #1069. The following patch excerpt illustrates related hardening work in the same release:

typescript

      }

      if (key.accessType === 'servers') {
-        // For server-scoped keys, check if any server in the group is allowed
+        // For server-scoped keys, the group is only accessible when every
+        // server in it is allowed (full containment). A key scoped to one
+        // group member must not gain access to the whole group (GHSA-454m-4vm6-842f).
        const allowedServers = key.allowedServers || [];
        if (allowedServers.length === 0) {
          return false;

Source: GitHub Commit Reference

Workarounds

Enforce egress network policies that block outbound connections to RFC1918, loopback, link-local, and cloud metadata addresses regardless of IPv6 encoding.
Front MCPHub with a forward proxy that resolves URLs, decodes IPv6 transition addresses, and rejects private destinations.
Disable IPv6 on the MCPHub host if the deployment does not require IPv6 connectivity for legitimate MCP servers.

bash

# Example iptables/ip6tables egress hardening for MCPHub host
ip6tables -A OUTPUT -d 64:ff9b::/96 -j REJECT
ip6tables -A OUTPUT -d 2002::/16   -j REJECT
ip6tables -A OUTPUT -d 2001::/32   -j REJECT
iptables  -A OUTPUT -d 169.254.169.254 -j REJECT
iptables  -A OUTPUT -d 127.0.0.0/8 ! -o lo -j REJECT