CVE-2026-58196: ToolHive SSRF in remote MCP server authentication discovery

• Affected versions: all versions before 0.31.0. The reproduction uses ToolHive v0.30.0 as the vulnerable build and v0.31.0 as the fixed negative control.
• Risk level and consequences: CWE-918 server-side request forgery. A malicious or compromised remote MCP server can cause the ToolHive host process, outside the intended per-server container isolation boundary, to fetch attacker-selected internal URLs. In a real deployment this can expose internal HTTP services or metadata endpoints reachable from the host.

Impact Parity

• Disclosed/claimed maximum impact: host-side SSRF during remote MCP server authentication discovery.
• Reproduced impact from this run: host-side HTTP GET from ToolHive v0.30.0 to an attacker-selected loopback canary URL after an attacker-controlled RFC 9728 resource_metadata endpoint issues a 302 redirect.
• Parity: full.
• Not demonstrated: no secrets were targeted or exfiltrated. The lab intentionally used a local canary and recorded only request path, headers, and redirect behavior.

Root Cause

In vulnerable ToolHive v0.30.0, FetchResourceMetadata(ctx, metadataURL) in pkg/auth/discovery/discovery.go constructs a normal http.Client for a server-supplied RFC 9728 resource metadata URL. That client has no CheckRedirect policy and no private/loopback/link-local dial guard. Therefore, after the remote MCP endpoint returns WWW-Authenticate: Bearer ... resource_metadata="<attacker URL>", ToolHive fetches the attacker metadata URL and automatically follows HTTP 30x redirects to a different host/port. This occurs in the host-side authentication discovery path, before/outside any per-server container sandbox.

The v0.31.0 fix changes the discovery clients to enforce redirect and private-address protections: DetectAuthenticationFromServer and metadata/OIDC discovery use networking.SameHostRedirectPolicy(), FetchResourceMetadata accepts a blockPrivateIPs setting, and the protected HTTP transports can use networking.NewPrivateIPBlockingDialContext(). The same-host redirect policy refuses redirects to a different host:port and HTTPS-to-HTTP downgrades, which prevents the demonstrated cross-port loopback canary request.

Reproduction Steps

1. Run bundle/repro/reproduction_steps.sh.
2. The script:
   • Uses the prepared project cache when available (<project_cache_dir>/repo and <project_cache_dir>/bin) and downloads exact ToolHive release binaries for v0.30.0 and v0.31.0 if not already cached.
   • Starts a malicious remote MCP HTTP endpoint and a separate loopback canary HTTP endpoint in a closed lab network.
   • Invokes the real product workflow twice per version: thv run <malicious-url> --remote-auth --remote-auth-skip-browser --foreground.
   • The malicious MCP endpoint returns a WWW-Authenticate header with an attacker-controlled resource_metadata URL. That metadata endpoint returns a 302 redirect to the separate canary.
   • Records per-attempt ToolHive, malicious endpoint, and canary logs under bundle/logs/, and writes bundle/repro/runtime_manifest.json before exit.
3. Expected evidence:
   • ToolHive v0.30.0: both vulnerable attempts reach the malicious endpoint and the canary receives one ToolHive host-side request per attempt.
   • ToolHive v0.31.0: both fixed attempts reach the malicious endpoint but the canary remains untouched.

Evidence

• Main run log: bundle/logs/reproduction_steps.log
  • Shows two vulnerable successes and two fixed negative controls:
    • vulnerable attempt 1: malicious requests=6, canary requests=1
    • vulnerable attempt 2: malicious requests=6, canary requests=1
    • fixed attempt 1: malicious requests=6, canary requests=0
    • fixed attempt 2: malicious requests=6, canary requests=0
    • [CONFIRMED] CVE-2026-58196 reproduced with vulnerable/fixed divergence.
• Vulnerable ToolHive product log: bundle/logs/toolhive_vulnerable_attempt1.log
  • Confirms the real thv run remote MCP workflow and host-side discovery path:
    • Attempting to run remote MCP server: http://127.0.0.1:<port>
    • Detected authentication requirement from server with resource_metadata set to the attacker endpoint.
    • Fetching resource metadata for that attacker URL.
• Malicious endpoint log: bundle/logs/malicious_server_vulnerable_attempt1.log
  • Records the initial ToolHive request to /, the RFC 9728 metadata redirect at /metadata-redirect/vulnerable/1, and the redirect location pointing at the separate canary URL.
• Canary log: bundle/logs/canary_vulnerable_attempt1.log
  • Records the vulnerable host-side SSRF oracle:
    • method: GET
    • path: /internal-canary/vulnerable/1/metadata.json
    • Referer: http://127.0.0.1:<malicious-port>/metadata-redirect/vulnerable/1
    • User-Agent: Go-http-client/1.1
• Fixed product logs: bundle/logs/toolhive_fixed_attempt1.log, bundle/logs/malicious_server_fixed_attempt1.log, and bundle/logs/canary_fixed_attempt1.log
  • The fixed build reaches the malicious remote endpoint but the corresponding canary log stays empty, demonstrating the v0.31.0 redirect/private-dial protection blocks the canary fetch.
• Structured evidence manifest: bundle/repro/runtime_manifest.json.
• Attempt summary: bundle/artifacts/toolhive-ssrf/attempts.jsonl.

Recommendations / Next Steps

• Upgrade ToolHive to v0.31.0 or later.
• Keep same-host redirect restrictions and private/loopback/link-local dial blocking on every HTTP client that fetches URLs derived from remote MCP server responses, including RFC 9728 metadata, OIDC discovery, and dynamic client registration discovery.
• Add regression tests for: resource_metadata redirects to different host/port, redirects from public targets to private/loopback/link-local addresses, HTTPS-to-HTTP downgrade redirects, and DNS/private-IP rebinding during discovery.
• Ensure future remote discovery features explicitly distinguish operator-configured trusted URLs from server-supplied URLs and apply stricter SSRF guards to the latter.

Additional Notes

• Idempotency confirmation: bundle/repro/reproduction_steps.sh was run twice consecutively after finalization and succeeded both times with the same vulnerable/fixed divergence.
• The lab does not contact real cloud metadata or third-party services. It uses a local malicious endpoint and a local canary as a safe stand-in for an internal service.
• The script attempts to bind a public-looking lab address for the remote endpoint, but if the sandbox cannot add/bind that address it falls back to loopback. The fixed-version negative control remains valid because v0.31.0 refuses the cross-host/cross-port redirect before the canary request is made.