CVE-2026-58196: ToolHive Fixes Host-Side MCP SSRF

api network free stock image for MCPwatch editorial use
Free stock image for MCPwatch editorial use. Source: Openverse/flickr. Original: Facebook fanpage apps. Creator: Detlef La Grand. License: by 2.0. License URL: https://creativecommons.org/licenses/by/2.0/. Original page: https://www.flickr.com/photos/30349080@N05/7041936735

CVE-2026-58196 covers server-side request forgery in ToolHive’s host-side authentication discovery for remote Model Context Protocol servers. GitHub’s reviewed records identify ToolHive versions before 0.31.0 as affected and 0.31.0 as the first patched version.

This is a vulnerability report, not an incident report. The vendor advisory describes a researcher reproduction, but no source reviewed by MCPwatch reports exploitation in the wild. MCPwatch did not independently execute the proof of concept or test the patch.

What the advisory establishes

The ToolHive repository advisory says remote MCP authentication discovery made outbound requests from the ToolHive host process without consistently blocking private addresses or constraining redirects. A remote server could influence discovery metadata so that the host requested an internal HTTP resource. Because the discovery request ran outside the MCP server’s container, the request crossed the isolation boundary operators might otherwise expect to contain an untrusted server.

The GitHub Advisory Database record maps the issue to CWE-918. Its structured package data lists the Go module github.com/stacklok/toolhive, versions below 0.31.0 as vulnerable, and 0.31.0 as patched. The record carries CVSS 3.1 4.7 and CVSS 4.0 2.9. These are source-assigned scores, not a new MCPwatch severity judgment.

Why the host-side boundary matters

ToolHive runs MCP servers in isolated containers, but remote authentication discovery is performed by ToolHive itself. The advisory’s proven primitive is therefore a host-originated GET request to a server-influenced destination, including an internal address reached directly or after a redirect. Potentially reachable resources depend on the host network, routing, cloud metadata configuration, and protections on internal services.

The report does not establish that every cloud metadata service yields credentials. It specifically notes that redirect-following GET behavior can reach broader internal HTTP services and older AWS IMDSv1 configurations, while IMDSv2 requires a token flow and other platforms may require headers the described request does not supply. Operators should preserve these conditions instead of converting an SSRF finding into an unsupported universal credential-theft claim.

Exposure also requires an operator to configure or use a remote MCP server whose discovery responses are malicious or compromised. The affected path is not evidence that every local, stdio, or unauthenticated MCP workload was exposed. Deployment review should distinguish remote-auth discovery from containerized server execution, because the vulnerable request originated in the host process before the expected per-server network boundary could apply.

Patch mechanics and release boundary

The linked fix commit adds a same-host redirect policy, refuses HTTPS-to-HTTP downgrades, caps redirect chains, and blocks private, loopback, or link-local destinations when the operator-configured target is public. The commit also preserves intentional access to internal authentication metadata when the configured MCP target itself is internal.

That commit landed in the project’s ToolHive 0.31.0 release line. The release summary does not call out the CVE by number, but the repository advisory and GitHub package range both use 0.31.0 as the fixed boundary. At retrieval time, ToolHive 0.38.0 was the latest GitHub release. Operators should evaluate the current supported release rather than treating the minimum patched version as a permanent pin.

Record and severity discrepancies

The repository advisory text still contains discovery-era wording that calls the issue “High” and says releases through 0.29.3 were affected. Its structured fields were later updated to Medium and before 0.31.0. GitHub’s global advisory response exposes the same 4.7 CVSS 3.1 vector but labels its top-level severity “low,” while the repository record labels it “medium.” MCPwatch therefore reports the numerical vectors and the current structured version boundary, while flagging the label mismatch rather than choosing between them.

The CVE Services API returned CVE_RECORD_DNE for CVE-2026-58196 when checked. The identifier and package details currently come from GitHub’s reviewed advisory records; an eventual CVE record may clarify or change metadata. This publication should be updated if the CNA record materially differs.

Defensive actions for ToolHive operators

  1. Identify the running version. Record the ToolHive binary or image version from the deployed environment, not only a repository checkout or desired-state file.
  2. Upgrade to a current supported release. Move beyond 0.31.0, restart the service, and verify that no older binary, container image, or operator instance remains active.
  3. Inventory remote-auth use. Determine which remote MCP servers use authentication discovery and which hosts initiated those connections.
  4. Constrain host egress. Apply network policy that prevents the ToolHive host from reaching unnecessary link-local, loopback, management, and private service endpoints.
  5. Harden cloud metadata. Require modern metadata protections, narrowly scope workload credentials, and avoid relying on application validation as the only barrier.
  6. Review available evidence. Examine ToolHive, proxy, DNS, firewall, cloud, and internal-service logs for unexpected discovery-time destinations. A vulnerable version alone is not proof of compromise.
  7. Re-test intended internal targets. If ToolHive deliberately connects to an internal MCP server, verify authentication discovery still reaches the expected internal issuer after upgrading.

Scope and uncertainty

The vulnerability and reproduction claims originate with the researcher and ToolHive advisory. MCPwatch verified the public advisory fields, fix commit, release tags, package boundary, CVSS values, and current CVE Services response. It did not reproduce the request path or assess a live deployment. Actual impact depends on whether remote authentication discovery was used and what the host could reach.

Sources