ToolHive MCP Server-Side Request Forgery via Authentication Discovery
First seen Sep 16, 2026 · Updated Sep 16, 2026 · CVSS 4.7
ToolHive's MCP client trusts remote-server-supplied authentication discovery URLs and follows redirects without restricting hosts or blocking private IP ranges, allowing a malicious or compromised MCP server to force the ToolHive host to make requests into internal networks. This can expose internal services and, in some configurations, retrieve cloud instance metadata credentials (e.g., unauthenticated IMDSv1). The issue is fixed in ToolHive 0.31.0.
Technical Analysis
The vulnerability lies in remote.Handler.Authenticate, which calls discovery.DetectAuthenticationFromServer to parse a WWW-Authenticate header from a remote MCP server. The server-controlled resource_metadata URL is extracted by ParseWWWAuthenticate and then dereferenced via FetchResourceMetadata, OIDC issuer discovery, and well-known endpoint discovery — none of which validate destination host/scheme or block link-local, RFC1918, or other private address ranges (IsPrivateIP is not invoked in this code path). This turns a trusted client-to-server MCP connection into an SSRF primitive: the user intends to connect to a specific remote MCP server, but that server can redirect the ToolHive host's outbound HTTP requests to arbitrary internal targets, crossing the boundary between the intended external MCP endpoint and the host's internal network. The demonstrated impact includes probing internal-only services (reachability/error oracles) and retrieving unauthenticated IMDSv1 cloud credentials, though IMDSv2 and GCP metadata endpoints are not exploitable via this specific request pattern.
Affected Systems
ToolHive; protocols: MCP
Detection Signatures
- Outbound HTTP GET requests from ToolHive host to RFC1918/link-local addresses (e.g., 169.254.169.254, 10.0.0.0/8, 192.168.0.0/16) originating from auth discovery code paths
- WWW-Authenticate response headers containing resource_metadata URLs pointing to internal/private hosts
- Unexpected outbound requests to /.well-known/oauth-authorization-server or OIDC issuer discovery endpoints on non-external hosts
- HTTP redirect chains during MCP authentication that change host or scheme mid-flow
- Unauthenticated GET requests to 169.254.169.254/latest/meta-data (IMDSv1) correlated with MCP client process
Remediation Steps
- 1
Upgrade ToolHive
Update to ToolHive 0.31.0 or later, which fixes the unvalidated authentication discovery HTTP client behavior.
- 2
Enforce private-IP blocking
Ensure all outbound HTTP clients used for OIDC/well-known discovery and resource metadata fetches validate destination IPs against private/link-local ranges before and after redirect resolution.
- 3
Restrict redirect following
Configure HTTP clients involved in authentication discovery to disallow cross-host or cross-scheme redirects, or to re-validate the destination on every redirect hop.
- 4
Network egress controls
Apply network-level egress filtering or a proxy that blocks requests from MCP client hosts to RFC1918, link-local, and cloud metadata addresses.
- 5
Disable IMDSv1
Where ToolHive or MCP clients run in cloud environments, enforce IMDSv2-only (or GCP metadata header requirements) to prevent unauthenticated metadata credential retrieval even if SSRF occurs.
- 6
Treat remote MCP servers as untrusted
Audit and restrict which remote MCP servers are permitted to connect, since any connected server can supply attacker-controlled discovery URLs.
CVE / Advisory IDs
Industries Most Exposed
Respond to this threat
Pro subscribers get a full AI-generated incident-response playbook for this threat — detection, containment, eradication, and recovery steps — plus an unlimited AI Threat Advisor for questions about your environment.