ToolHive Auth Discovery Escaped MCP Container Isolation via Host-Side SSRF — CVE-2026-58196
A server-side request forgery flaw in ToolHive allowed a malicious or compromised remote Model Context Protocol server to make the ToolHive host fetch internal URLs during authentication discovery. That placement is the important part: ToolHive runs MCP servers in isolated containers and offers egress controls, but the vulnerable discovery requests occurred in the host process before and outside the per-server sandbox.
The issue is tracked as CVE-2026-58196 and GHSA-pr64-jmmf-jp54. GitHub's structured advisory data identifies versions before 0.31.0 as vulnerable and 0.31.0 as the first patched release. The advisory was published July 15, after the fixed release had shipped on June 24. Operators should verify the running binary rather than assume a container boundary contains remote-authentication traffic.
An untrusted server selected a trusted host request
In the demonstrated path, a remote MCP server returned an HTTP 401 response with a WWW-Authenticate header. Its attacker-controlled resource_metadata value then became the destination for ToolHive's OAuth metadata fetch. The client required the initial metadata URL to use HTTPS, but it did not block private or link-local addresses and would follow a redirect to another host or to HTTP.
A server could therefore point the initial HTTPS request back to itself and answer with a redirect to an internal address such as 169.254.169.254. The victim did not have to enter that internal target; adding and authenticating to the remote MCP server was enough to trigger discovery. Related issuer and well-known metadata probes used the same unguarded client pattern.
The report dynamically reproduced an internal GET from the ToolHive host. On an AWS instance where legacy IMDSv1 remains enabled, a plain GET can return role credentials. That credential result does not generalize to every metadata service: AWS IMDSv2 requires a token obtained with a PUT request, while Google Cloud metadata requires a header a redirect does not supply. Even there, the primitive still reaches internal HTTP services and can expose timing or reachability information.
The vulnerability crossed the security product's own boundary
SSRF severity cannot be judged from the URL parser alone. ToolHive's value proposition is to contain untrusted MCP execution, so a host-side network request driven by that server crosses the exact boundary the deployment is meant to create. The container can have no credentials and tightly restricted egress while the parent process still sees node-local, link-local, and RFC1918 services.
The advisory also documents three #nosec G704 suppressions on the affected requests. Their comments treated the destination as trusted because it came from MCP endpoint configuration or a well-known metadata endpoint. In practice, later discovery values came from the remote server. This is a useful code-review failure pattern: data can enter through a trusted configuration object and still become attacker-controlled after protocol negotiation.
Severity labels require care. The advisory narrative calls the issue high severity, while GitHub currently labels it low with CVSS 3.1 score 4.7 and vector AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N. The lower score reflects required user interaction and bounded direct impact; it does not erase the architectural significance of escaping the intended network boundary.
The patch binds redirects and addresses to policy
ToolHive's June 24 fix added a same-host redirect policy to the three discovery sinks. Redirects are limited to the original host and port, HTTPS-to-HTTP downgrades are refused, and redirect chains are capped. For public configured targets, server-influenced metadata fetches also use a dial-time private-IP block on every hop. Operators intentionally connecting to internal servers retain an explicit path for private destinations.
That combination matters. Validating only the first URL does not stop an HTTPS endpoint from redirecting to an internal HTTP service, and validating only the hostname before dialing does not stop DNS answers from changing. The enforcement point needs to re-check the resolved address at connection time and apply redirect policy for every transition.
This issue is distinct from CVE-2026-54450, a separate ToolHive advisory about NAT64 ranges missing from an existing SSRF classifier. CVE-2026-58196 did not need to bypass that classifier because the affected discovery clients did not call it at all.
Defensive engineering guidance
- Upgrade ToolHive to 0.31.0 or later. Check the version of every CLI, operator image, gateway, and long-running host process; rebuild pinned images and restart them after upgrade.
- Audit remote MCP enrollment. Review servers added from registries or shared configuration, especially endpoints that changed ownership, returned unusual 401 responses, or redirected during OAuth discovery.
- Inspect host egress. Search DNS, proxy, flow, and process telemetry for ToolHive connections to loopback, link-local, RFC1918, cluster-service, and cloud-metadata destinations. Investigate unexpected metadata paths even when responses were blocked.
- Disable AWS IMDSv1. Require IMDSv2, restrict hop limits, and use narrow instance roles. Metadata hardening reduces the value of a GET-only SSRF but does not replace application fixes.
- Separate control-plane networking. Run the ToolHive host with its own egress policy and block metadata and internal management networks. Sandboxing only child MCP containers leaves host-side protocol clients outside the rule.
- Threat-model protocol discovery. Treat authentication challenges, issuer metadata, registration endpoints, pagination links, webhooks, and redirects as untrusted destinations even when the initial server URL was administrator-approved.
- Review security suppressions as assumptions. A static-analysis waiver should name the trust boundary and the enforcing control. Revisit it whenever later protocol steps can replace or redirect the original value.
CVE-2026-58196 demonstrates why agent isolation must include the orchestration process, not only the tool container. A remote MCP server did not need to break out of its sandbox; it could ask a more privileged host-side client to cross the boundary on its behalf. Strong containment binds every outbound request—including authentication discovery—to an expected destination and resolves that policy again at redirect and dial time.
Sources: