ToolHive MCP Server Network Isolation Bypass and Unauthenticated Proxy Access

Technical Analysis

The vulnerability stems from ToolHive's default network permission profile failing to isolate MCP server containers, combined with ToolHive Studio explicitly setting network_isolation to false, overriding the backend's secure default. This leaves host.docker.internal reachable from within containers, and the ToolHive API plus MCP proxy endpoints accept unauthenticated requests. An attacker controlling one MCP server (e.g., via a poisoned tool package or supply-chain compromise) can use the Docker gateway to invoke sibling MCP tools, read logs and data from the control plane, and alter workload or process state on other agent instances. This crosses the intended isolation boundary between independently deployed MCP servers, turning a single compromised tool into a foothold for lateral movement across an entire multi-agent MCP deployment.

Affected Systems

ToolHive CLI, ToolHive Studio; protocols: MCP

Detection Signatures

• Outbound requests from MCP server containers to host.docker.internal or Docker bridge gateway IPs not expected for that tool's function
• Unauthenticated requests to ToolHive API or MCP proxy endpoints (absence of auth headers/tokens in access logs)
• network_isolation:false in ToolHive Studio configuration or workload manifests
• Cross-container calls between MCP proxies not initiated by the orchestrating agent
• Unexpected process/workload state changes correlated with inbound traffic from sibling containers

Remediation Steps

1. 1

   Upgrade ToolHive

   Update to ToolHive CLI 0.30.1+ or ToolHive Studio 0.38.0+, which restore secure network isolation defaults.

2. 2

   Enforce network isolation explicitly

   Verify and enforce network_isolation:true in all ToolHive Studio and CLI configurations; do not rely on defaults after upgrade.

3. 3

   Add authentication to control plane

   Require authentication/authorization on the ToolHive API and MCP proxy endpoints; do not expose them on shared or reachable network segments without access controls.

4. 4

   Restrict Docker gateway access

   Use container network policies to block unnecessary access to host.docker.internal and other containers unless explicitly required by the tool's function.

5. 5

   Audit MCP server provenance

   Only run MCP servers from trusted, vetted sources given that any single compromised server can now pivot laterally if unpatched.