CVE-2026-79749 in MCPHub
Summary
by MITRE • 08/31/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/31/2026
MCPHub serves as a centralized orchestration platform designed to manage multiple Model Context Protocol servers and APIs by routing requests through flexible strategies. The security architecture of this system relies heavily on server-side request forgery protections to prevent internal network exposure. Prior to version 1.0.32, the implementation of these safeguards contained a critical logic flaw within the source file src/utils/ssrf.ts. Specifically, the custom function isBlockedIpv6 was responsible for validating IPv6 addresses against a blacklist of dangerous address ranges. This validation mechanism was incomplete because it only checked for loopback, link-local, unique-local, and standard IPv4-mapped or compatible IPv6 formats. It failed to account for specific IPv6 transition mechanisms that are commonly used in modern network infrastructure, creating a significant gap in the defense-in-depth strategy employed by the application.
The technical flaw stems from an incomplete understanding of how private IP addresses can be encapsulated within various IPv6 address families. While standard checks blocked direct access to local networks via common IPv6 representations, they did not consider NAT64 (prefix 64:ff9b::/96), 6to4 (2002::/16), and Teredo (2001::/32) transition addresses. These address families are designed to facilitate communication between IPv6-only networks and legacy IPv4 infrastructure. An attacker who has the ability to specify or influence the URL target for an MCP server connection can exploit this oversight by encoding a private IPv4 address, such as 192.168.1.1 or 10.0.0.5, into one of these transition formats. For instance, using NAT64 translation rules, an attacker could construct a URL that resolves to the internal IP while appearing syntactically valid and non-blocked by the SSRF guard. This allows the request to bypass security filters and reach services running on the local network or other protected internal infrastructure that would otherwise be inaccessible from external sources.
The operational impact of this vulnerability is severe, as it effectively neutralizes a primary defense against server-side request forgery attacks in environments where MCPHub processes untrusted URLs. By leveraging IPv6 transition mechanisms to mask private IP addresses, an attacker can probe internal services, exfiltrate data from local databases, or interact with administrative interfaces that are not exposed to the public internet. This aligns with CWE-918, which describes Server-Side Request Forgery (SSRF) flaws where server-side code makes requests based on user-supplied input without proper validation of the destination address. Furthermore, this exploitation technique relates to ATT&CK tactic T1071, Application Layer Protocol, specifically sub-techniques involving web protocols, as it involves manipulating network layer addressing within application-level HTTP or API calls to achieve unauthorized access. The ability to reach internal infrastructure can lead to further compromise of the broader system environment, potentially allowing lateral movement or data theft depending on what services are exposed internally.
To mitigate this vulnerability and prevent similar issues in future developments, MCPHub version 1.0.32 has patched the isBlockedIpv6 function to include checks for NAT64, 6to4, and Teredo address ranges. Organizations using earlier versions must upgrade immediately to ensure that these transition addresses are correctly identified as dangerous and blocked. In addition to upgrading, security teams should implement defense-in-depth strategies such as network segmentation to limit the blast radius of any potential SSRF exploits. It is also recommended to validate not just IP addresses but also DNS resolution results to detect fast-flux or other evasion techniques that might attempt to bypass static address checks. Regular audits of URL validation logic against evolving IPv6 transition standards are essential to maintain robust security posture in network-facing applications.