Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-08-31T18:17:20.200Z",
  "pubdate": "2026-08-31T18:17:20.200Z",
  "executiveSummary": "MCPHub prior to version 1.0.32 contains a critical Server-Side Request Forgery (SSRF) vulnerability. This flaw allows an authenticated non-admin user to configure the hub to initiate arbitrary outbound HTTP requests to internal or external resources without network egress filtering.\nThe vulnerability exposes the underlying infrastructure to unauthorized interactions with local services, including RFC1918 addresses, loopback interfaces, and link-local addresses such as 169.254.0.0/16. Attackers can leverage the OpenAPI proxy path to exfiltrate response data or utilize the SSE/streamable-http transport for blind exploitation.\nThis vulnerability poses significant risk, potentially allowing an attacker to map internal network topology, interact with metadata services, or perform actions on behalf of the hub within the trusted environment.\nSuccessful exploitation requires the attacker to hold an authenticated user account within the MCPHub instance. The issue was addressed in version 1.0.32 through the implementation of restricted request egress controls.",
  "technicalDetails": "The vulnerability resides in the server registration mechanism within MCPHub, which failed to perform input validation or enforce egress filtering on user-provided server URLs. By registering an arbitrary server endpoint, an authenticated user influences the server-side request architecture of the hub, triggering HTTP calls to locations controlled by the attacker.\nThe attack vector bifurcates based on the chosen transport or proxy method. When utilizing the OpenAPI proxy path, the application functions as a full reflected SSRF proxy; the hub executes the request to the attacker-defined URL and reflects the full response body back to the user, facilitating direct exfiltration of internal data, sensitive service responses, or metadata.\nAlternatively, using the SSE/streamable-http transport mechanism allows for blind SSRF attacks. While this method does not return the response body, it enables the attacker to probe the internal network's responsiveness to specific requests, facilitating port scanning, service discovery, and interaction with internal APIs or legacy endpoints that may rely on IP-based trust models.\nThe lack of sanitization allows for requests targeting sensitive network segments including loopback (127.0.0.1), private RFC1918 subnets (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and the cloud provider instance metadata service (169.254.169.254). Because the hub is responsible for orchestrating and managing these connections, the requests originate from the hub's execution environment, bypassing perimeter firewalls.\nThe exploitation flow proceeds as follows: 1) The authenticated attacker submits a registration request for a new MCP server, providing a malicious URI targeting an internal resource. 2) The MCPHub process validates the registration and proceeds to instantiate a connection to the provided URI. 3) The server-side request is initiated without any validation or egress filtering. 4) The hub transmits the response data back to the attacker via the proxy path or confirms the state change of the blind request, allowing for successful data exfiltration or internal service interaction."
}