ToolHive's remote MCP server authentication discovery issues outbound HTTP requests to attacker-controlled URLs without applying private IP or loopback address guards or redirect restrictions. Although ToolHive runs MCP servers in isolated containers and uses an egress proxy for network isolation, this discovery code executes on the host itself, outside container isolation. A malicious remote MCP server can exploit this by supplying URLs that cause the host to fetch internal resources such as cloud instance metadata, bypassing the intended isolation. The discovery clients explicitly suppress security warnings assuming the URLs are trusted, but this trust assumption is incorrect as the URLs originate from the untrusted remote MCP server. Existing protections like ValidateRemoteURL and IsPrivateIP are not used in this discovery path, and the vulnerability is distinct from other SSRF issues previously reported in ToolHive. The vulnerability affects all versions before 0.31.0, with no known exploits in the wild and no vendor patch currently available.

An attacker controlling or compromising a remote MCP server can induce the ToolHive host to make arbitrary HTTP requests to internal or private network resources, including cloud instance metadata endpoints. This bypasses ToolHive's container isolation and network egress proxy protections, potentially exposing sensitive internal information or enabling further attacks on the host environment. The vulnerability undermines the core security model of ToolHive by allowing SSRF attacks from an untrusted MCP server to the host system.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, users should be aware that the discovery clients do not apply private IP or redirect restrictions and treat remote MCP server URLs as trusted, which is unsafe. Operators should avoid adding untrusted or unknown MCP servers and monitor ToolHive updates for a forthcoming official fix addressing this SSRF vulnerability.