CVE-2026-79747 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, an authenticated non-admin user can register a server pointing at an arbitrary URL and make the hub issue server-side requests to it, with no egress filtering (no block of loopback / RFC1918 / link-local 169.254.0.0/16). Via the OpenAPI proxy path the response body is returned to the caller (full, reflected SSRF); via the SSE/streamable-http transport the request is sent blind. This issue has been patched in version 1.0.32.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/31/2026
MCPHub serves as a centralized orchestration platform designed to manage and route requests across multiple Model Context Protocol servers through flexible routing strategies. The architecture relies on an authenticated user base, distinguishing between administrative privileges for core configuration and standard access for operational tasks. However, prior to version 1.0.32, the system contained a critical server-side request forgery vulnerability that exploited insufficient input validation regarding destination URLs registered by non-administrative users. This flaw allowed any authenticated user with permission to register new servers to specify arbitrary external or internal endpoints rather than legitimate MCP service addresses. The security model failed to implement egress filtering mechanisms, meaning the application did not restrict outbound connections based on IP address ranges such as loopback interfaces, RFC1918 private networks, or link-local addresses like 169.254.0.0/16. This absence of network-level controls effectively turned the MCPHub instance into an open proxy capable of initiating requests to any reachable host within the internal infrastructure or external internet.
The operational impact of this vulnerability is severe due to its dual nature in terms of data exfiltration and reconnaissance capabilities. When attackers utilize the OpenAPI proxy path, they achieve a full reflected server-side request forgery scenario where the response body from the target service is returned directly to the attacker's client. This allows for sensitive information disclosure, including internal API responses, configuration files, or authentication tokens stored on backend services that are not intended for public access. Conversely, when using the SSE or streamable-http transport mechanisms, the vulnerability operates in a blind SSRF mode where requests are sent without returning immediate feedback to the caller. While this limits direct data leakage through response reflection, it still enables attackers to perform internal network scanning, trigger actions on vulnerable backend services such as cloud metadata endpoints, and potentially chain with other vulnerabilities for remote code execution or privilege escalation within the target environment.
This vulnerability aligns closely with CWE-918 Server-Side Request Forgery (SSRF), specifically reflecting the failure to validate user-supplied input against a list of allowed destinations before processing it on the server side. From an offensive security perspective, this behavior maps directly to MITRE ATT&CK technique T1557, which covers Adversary-in-the-Middle scenarios where attackers intercept or manipulate communications between clients and servers. The ability to bypass egress filtering also relates to CWE-442, Deprecation of HTTP Basic Authentication if legacy systems are targeted, but more critically it represents a fundamental failure in network segmentation enforcement within the application layer. Attackers can leverage this flaw to access internal services that lack their own authentication mechanisms or rely on IP-based trust relationships, thereby bypassing perimeter defenses entirely by making requests appear as legitimate traffic originating from the trusted MCPHub server itself.
Mitigation strategies must prioritize immediate patching of the MCPHub software to version 1.0.32 or later, which addresses these validation gaps through enhanced input sanitization and strict egress filtering rules. Organizations should also implement network-level controls such as firewall policies that restrict outbound connections from application servers to only those destinations explicitly required for business operations. Additionally, deploying a reverse proxy with URL allow-listing capabilities can provide an additional layer of defense by validating request targets before they reach the MCPHub instance. Security teams should audit existing server registrations within the hub to identify any malicious entries created during potential exploitation windows and rotate credentials for all services that may have been accessed via this vulnerability. Regular penetration testing focusing on SSRF vectors in proxy-like applications is recommended to ensure no similar bypasses exist in other integrated components of the infrastructure.