CVE-2026-58196: 
Analyse et atténuation des vulnérabilités

CVE-2026-58196 is a Server-Side Request Forgery (SSRF) vulnerability in ToolHive's remote MCP server authentication discovery mechanism that allows a malicious or compromised remote MCP server to force the ToolHive host process to issue arbitrary internal HTTP requests, bypassing the container isolation that ToolHive is designed to enforce. The vulnerability affects all ToolHive releases through v0.29.3 and was originally identified at commit 05f11b53, with the flaw confirmed present at HEAD b672d82f (2026-06-12). It was published to the GitHub Advisory Database on July 15, 2026, with a patch available in v0.31.0. The CVSS v3.1 score is 4.7 (Medium) and the CVSS v4.0 score is 2.9 (Low), though the advisory internally rates severity as High due to the container isolation bypass (GitHub Advisory, ToolHive Advisory).

The root cause (CWE-918) lies in the FetchResourceMetadata, DetectAuthenticationFromServer, and OIDC issuer discovery HTTP clients in pkg/auth/discovery/discovery.go, which are constructed with no CheckRedirect handler and no private-IP dialer guard, despite the project's existing IsPrivateIP guard (pkg/networking/utilities.go:105) being available. When a user connects to a remote MCP server using thv run --remote-auth, ToolHive's host process automatically performs authentication discovery by issuing a GET to the server's endpoint; a 401 response with a WWW-Authenticate: Bearer resource_metadata="<URL>" header causes ToolHive to fetch the attacker-supplied resource_metadata URL. Because the client follows HTTP 302 redirects without re-validating the redirect target, an attacker can supply an HTTPS metadata URL (passing the one-time scheme check at discovery.go:911) that redirects to http://169.254.169.254/latest/meta-data/ or any RFC1918/link-local address. The three affected HTTP requests carry // #nosec G704 suppressions with comments asserting the URLs are trusted, but under ToolHive's own threat model the remote MCP server is untrusted input, making those suppressions incorrect (GitHub Advisory, ToolHive Advisory).

A successful exploit forces the ToolHive host process — not the sandboxed container — to issue arbitrary GET requests to internal addresses including cloud instance metadata endpoints, RFC1918 hosts, link-local addresses, and internal-only HTTP services. On AWS deployments with IMDSv1 enabled, a redirect to http://169.254.169.254/latest/meta-data/iam/security-credentials/ returns IAM credentials directly via a plain GET, enabling credential theft and potential lateral movement within the cloud environment. This directly undermines ToolHive's core security guarantee of container isolation, since the discovery code executes in the host process before the per-server sandbox is applied (GitHub Advisory, ToolHive Advisory).

1. Set up a malicious MCP server: The attacker operates or compromises a remote MCP server reachable by the victim (e.g., via a public registry, shared config, or supply-chain compromise of a previously legitimate endpoint).
2. Configure the SSRF redirect chain: The malicious server is configured to respond to any authentication discovery request with HTTP 401 and a WWW-Authenticate: Bearer realm="x", resource_metadata="https://<attacker-controlled-host>/.well-known/oauth-protected-resource" header. The attacker-controlled HTTPS endpoint is set to return HTTP 302 Location: http://169.254.169.254/latest/meta-data/iam/security-credentials/ (or any other internal target).
3. Victim adds the server: The victim adds the malicious server to ToolHive using the normal remote-server workflow (e.g., thv run --remote-auth <server-url>).
4. Trigger automatic discovery: ToolHive's host process automatically calls remote.Handler.Authenticate → discovery.DetectAuthenticationFromServer, issuing a GET to the server endpoint. The 401 response is parsed by ParseWWWAuthenticate (discovery.go:293), and the attacker-supplied resource_metadata URL is stored.
5. SSRF via redirect: tryDiscoverFromResourceMetadata calls FetchResourceMetadata (discovery.go:899), which builds an HTTP client with no CheckRedirect and no private-IP guard, fetches the HTTPS metadata URL (passing the scheme check), and follows the 302 redirect to the internal address without re-validation.
6. Exfiltrate internal data: The ToolHive Go HTTP client (Go-http-client/1.1) delivers the GET request to the internal endpoint. On AWS IMDSv1, the response contains IAM credentials; on other targets, the attacker receives internal service responses or reachability oracles (GitHub Advisory, ToolHive Advisory).

• Network: Outbound HTTP GET requests from the ToolHive host process (Go-http-client/1.1 user-agent) to 169.254.169.254, RFC1918 addresses, or link-local ranges (169.254.0.0/16) that are not expected in normal operation; unexpected HTTP requests to internal-only services originating from the ToolHive process.
• Logs: ToolHive application logs showing authentication discovery attempts (DetectAuthenticationFromServer, FetchResourceMetadata) against unusual or internal URLs; HTTP 302 redirect chains in outbound request logs where the final destination is an internal address.
• Process: The ToolHive host process (thv) making network connections to cloud metadata endpoints or internal HTTP services during MCP server authentication discovery, particularly when --remote-auth is used.
• File System: Unexpected credential files or tokens written to disk if an attacker exfiltrates and stages IAM credentials or other secrets retrieved via the SSRF (GitHub Advisory).

Upgrade ToolHive to version v0.31.0 or later, which patches the vulnerability by applying the DCR client's hardening to the discovery clients: setting CheckRedirect to reject cross-host or scheme-downgrade redirects, and wrapping DialContext with the existing IsPrivateIP guard for FetchResourceMetadata, DetectAuthenticationFromServer, and the issuer-discovery client. No configuration-based workaround is available for unpatched versions, as the flaw is in host-side code that runs automatically during remote server authentication discovery. As an interim measure, avoid adding untrusted or unverified remote MCP servers to ToolHive deployments, particularly in cloud environments with IMDSv1 enabled (GitHub Advisory, ToolHive Advisory).

The advisory credits researcher bIackr0se as the reporter, with remediation reviewed by jhrozek, JAORMX, ChrisJBurns, and rdimitrov from the ToolHive/Stacklok team. The advisory notes that the maintainers had previously suppressed the relevant gosec SSRF taint-analysis warnings (G704) with comments asserting the URLs were trusted, which the reporter identifies as the root cause of the oversight. No significant broader media coverage or social media discussion has been identified at this time (GitHub Advisory).