Skip to main content
A Leader in the 2026 Gartner® Magic Quadrant™ for Endpoint Protection. Six years running.Find Out Why
Vulnerability Database/CVE-2026-58197

CVE-2026-58197: ToolHive Auth Bypass Vulnerability

CVE-2026-58197 is an authentication bypass flaw in ToolHive that allows malicious MCP servers to access host services without authentication. This post covers technical details, affected versions, and mitigation.

Published:

CVE-2026-58197 Overview

ToolHive is a utility for deploying and managing Model Context Protocol (MCP) servers. Versions prior to ToolHive CLI 0.30.1 and ToolHive Studio 0.38.0 run local MCP server containers with a default network permission profile that lacks isolation. This configuration permits containers to reach host.docker.internal while the ToolHive API and MCP proxy endpoints remain reachable without authentication. A malicious or compromised MCP server can pivot through the Docker gateway to contact host-local services, sibling MCP proxies, or the ToolHive control plane. The weakness maps to [CWE-284: Improper Access Control].

Critical Impact

A compromised MCP container can access ToolHive control-plane and sibling MCP endpoints without escaping the container, exposing data, invoking sibling tools, and disrupting services.

Affected Products

  • ToolHive CLI versions prior to 0.30.1
  • ToolHive Studio versions prior to 0.38.0
  • Local MCP server container deployments managed by Stacklok ToolHive

Discovery Timeline

  • 2026-09-18 - CVE-2026-58197 published to NVD
  • 2026-09-24 - Last updated in NVD database

Technical Details for CVE-2026-58197

Vulnerability Analysis

The flaw is a missing access control boundary between MCP server containers and the ToolHive host environment. Local MCP containers launched by ToolHive inherit a permission profile without network isolation. From inside the container, an attacker-controlled MCP server can resolve host.docker.internal, gateway.docker.internal, and the Docker bridge address (172.17.0.1) to reach host-local services.

Because the ToolHive API and MCP proxy endpoints listen on these host-reachable interfaces without authentication, the compromised container can invoke sibling MCP tools, read logs, alter workload state, and disrupt other proxied services. No container escape is required; the attack occurs entirely over the Docker gateway.

ToolHive Studio compounds the exposure by explicitly sending network_isolation: false in workload creation requests, which overrides the backend's secure default and forces the insecure profile even when the server would otherwise enable isolation.

Root Cause

Two defects combine to produce the vulnerability. First, the CLI flag --isolate-network defaulted to false, so newly launched MCP containers received a permissive network profile. Second, the ToolHive Studio frontend sent an explicit false value for network_isolation, overriding backend defaults. The unauthenticated ToolHive API and MCP proxy listening on host-reachable addresses made the missing isolation directly exploitable.

Attack Vector

Exploitation requires an adjacent-network position and user interaction to run a malicious or compromised MCP server image under ToolHive. Once the container starts, its process can open TCP connections to host.docker.internal and enumerate ToolHive API and sibling MCP proxy ports. The attacker uses those unauthenticated endpoints to read data, invoke tools exposed by other MCP servers, or modify workload configuration through the control plane. Scope changes because the compromised MCP container reaches resources outside its intended authorization boundary.

go
// Patch: cmd/thv/app/run_flags.go - Default network isolation to on
// Source: https://github.com/stacklok/toolhive/commit/d8f40cb1599b8bf66657f2dfff15bfbfc236e712
-	cmd.Flags().BoolVar(&config.IsolateNetwork, "isolate-network", false,
-		"Isolate the container network from the host (default false)")
+	cmd.Flags().BoolVar(&config.IsolateNetwork, "isolate-network", true,
+		"Isolate the container network from the host. Use --isolate-network=false to opt out.")
 	cmd.Flags().BoolVar(&config.AllowDockerGateway, "allow-docker-gateway", false,
 		"Allow outbound connections to Docker gateway addresses (host.docker.internal, gateway.docker.internal, 172.17.0.1). "+
 			"Only applies when --isolate-network is set. These are blocked by default even when insecure_allow_all is enabled.")

See the ToolHive Security Advisory GHSA-qg2g-g9w3-m5h8 for full technical details.

Detect Identity Attacks the Moment Authentication Fails

Singularity™ Identity surfaces credential misuse, lateral movement, and privilege escalation in real time, so you can contain the breach before it spreads.

Stop Identity Attacks

Detection Methods for CVE-2026-58197

Indicators of Compromise

  • Outbound connections from MCP containers to host.docker.internal, gateway.docker.internal, or 172.17.0.1 on ToolHive API and proxy ports.
  • Unauthenticated HTTP requests to the ToolHive API originating from container network ranges rather than the local operator.
  • MCP workload configuration changes or tool invocations that do not correlate to actions in the ToolHive Studio UI or CLI session.

Detection Strategies

  • Inventory running ToolHive deployments and confirm CLI version >= 0.30.1 and Studio version >= 0.38.0.
  • Inspect workload creation payloads for an explicit network_isolation: false field, which indicates the vulnerable Studio behavior.
  • Review Docker network policies on hosts running ToolHive to identify containers with unrestricted access to the Docker gateway.

Monitoring Recommendations

  • Capture container-to-host traffic and alert on flows targeting Docker gateway addresses from MCP containers.
  • Log all ToolHive API requests with source IP so requests originating from container subnets can be reviewed.
  • Correlate MCP proxy invocations with the initiating client session to surface cross-tenant tool calls between sibling MCP servers.

How to Mitigate CVE-2026-58197

Immediate Actions Required

  • Upgrade ToolHive CLI to 0.30.1 and ToolHive Studio to 0.38.0 or later.
  • Restart any MCP workloads created before the upgrade so they inherit the new default network isolation profile.
  • Audit recently deployed MCP server images for untrusted sources and revoke any that cannot be verified.

Patch Information

The fixes are delivered in ToolHive CLI v0.30.1 and ToolHive Studio v0.38.0. The CLI change (PR #5583) flips the --isolate-network flag default from false to true. The Studio change (PR #2469) stops sending network_isolation: false and defers to the backend's secure default.

Workarounds

  • Pass --isolate-network=true explicitly when starting MCP servers with the vulnerable CLI.
  • Do not use --allow-docker-gateway unless a specific workload requires host-local access.
  • Restrict which users can launch MCP servers, and only run images from trusted, signed sources.
bash
# Enforce network isolation for local MCP servers on vulnerable CLI versions
thv run --isolate-network=true <mcp-server-image>

# Verify upgraded versions
thv version   # expect >= 0.30.1

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.

Try SentinelOne