MCPHub Authenticated SSRF via Arbitrary MCP Server Registration

Technical Analysis

The vulnerability arises because MCPHub's server registration feature does not validate or restrict destination URLs, allowing low-privilege authenticated users to specify loopback (127.0.0.1), link-local (169.254.0.0/16, including cloud metadata services), or RFC1918 private addresses as MCP server endpoints. The hub then acts as a proxy, issuing HTTP requests to these attacker-controlled targets on the user's behalf. Via the OpenAPI proxy path, the full response body is reflected back to the attacker, enabling direct data exfiltration (e.g., cloud instance credentials, internal API responses); via SSE/streamable-http transport, the request is blind but can still be used for internal network reconnaissance, port scanning, or triggering side effects on internal services. This crosses a privilege boundary since a non-admin user gains an admin-level capability (arbitrary outbound requests from the trusted hub infrastructure), effectively weaponizing the MCP orchestration layer as an SSRF pivot into the hosting environment's internal network.

Affected Systems

MCPHub; protocols: MCP

Detection Signatures

• MCP server registration requests with target URLs resolving to 127.0.0.1, ::1, 169.254.169.254, or RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
• Unexpected outbound HTTP requests from MCPHub host to internal-only services or cloud metadata endpoints
• Non-admin user accounts creating or modifying MCP server registrations
• OpenAPI proxy responses containing cloud credential material (AWS/GCP/Azure metadata response signatures)
• Anomalous SSE/streamable-http connections initiated to internal IP ranges shortly after new server registration events

Remediation Steps

1. 1

   Upgrade MCPHub

   Update to MCPHub version 1.0.32 or later, which patches this SSRF vulnerability.

2. 2

   Enforce egress filtering

   Implement network-level or application-level blocking of outbound requests to loopback, link-local (169.254.0.0/16), and RFC1918 private address ranges from the MCPHub host.

3. 3

   Restrict server registration privileges

   Require admin approval or elevated privileges for registering new MCP server endpoints rather than allowing any authenticated user to do so.

4. 4

   Implement URL allow-listing

   Restrict MCP server registration to a pre-approved allow-list of domains/IPs rather than accepting arbitrary URLs.

5. 5

   Audit existing registrations

   Review all currently registered MCP servers for suspicious internal or metadata-service URLs and remove unauthorized entries.

6. 6

   Isolate cloud metadata access

   Use IMDSv2 or equivalent metadata service hardening and network policies to prevent application servers from reaching instance metadata endpoints unnecessarily.