MCPHub MCPRouter baseUrl SSRF

How the attack works

An attacker submits a request to MCPHub that includes a baseUrl-family field (baseUrl, serverUrl, targetUrl, mcpUrl, endpoint, upstreamUrl, proxyUrl, callbackUrl, or webhookUrl) containing a crafted absolute URL. The crafted value points at a cloud metadata service, uses a non-HTTP scheme, disguises an IP address, or hides an internal host behind userinfo syntax. MCPRouter then dials that URL on the attacker's behalf, effectively acting as a proxy into internal or cloud-provider-only network space. The detection watches both the incoming request carrying the malicious parameter and the router's own outbound connection to the suspicious target, tying them together by tracing the exact process and session that handled the request.

Netzilo detection

Why it matters

A successful SSRF against MCPHub's router can expose cloud instance credentials from a metadata service, or let an attacker reach internal admin interfaces and services that are not meant to be internet-facing, potentially leading to further compromise.

What you can do

• →Upgrade MCPHub past 0.9.10 or apply the vendor's fix for the serverController.ts baseUrl handling.
• →Restrict or firewall the MCPRouter process's outbound network access so it cannot reach cloud metadata endpoints (169.254.169.254, metadata.google.internal) or internal-only address ranges.
• →Validate and allowlist baseUrl-family parameters server-side rather than relying on client input, rejecting non-HTTP schemes, userinfo-embedded hosts, and obfuscated IP literals.
• →Review logs for MCPRouter connections to metadata endpoints or internal admin ports (2379, 6379, 10250) that are not explained by known infrastructure tooling in that session.

Known benign look-alikes

• Local development agents registering an MCP server whose baseUrl points at a loopback service on a non-standard port. This is a weak indicator only and is reported solely when MCPHub router context or internal fan-out is also present in the same process session.
• Cloud SDKs, CI runners and credential helpers polling the instance metadata service at 169.254.169.254 or metadata.google.internal. Metadata egress on its own is weak and needs a corroborating MCPHub or enumeration stage.
• Infrastructure tooling (Terraform providers, kubectl clients, service-mesh sidecars, Redis/Postgres admin UIs) legitimately reaching internal admin ports such as 2379, 6379 or 10250 from a monitored session.
• Documentation builds, integration tests and fixtures that POST example MCPHub server configurations containing baseUrl values pointing at loopback or metadata addresses.
• Authorised SSRF test suites and red-team exercises run against the organisation's own MCPHub deployment.

References

• https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/
• https://github.com/samanhappy/mcphub
• https://attack.mitre.org/techniques/T1190/