ToolHive containers can reach host services, advisory warns

Containerised MCP servers run by Stacklok's ToolHive can reach services on the host machine, according to a GitHub security advisory published on 18 September 2026. The flaw, tracked as CVE-2026-58197 and rated high severity in the advisory, lets a malicious or compromised MCP server move laterally to other tools and services without escaping its container.

MCP, the Model Context Protocol, is the interface agents use to call external tools. ToolHive's pitch is that it runs each MCP server inside a container to contain the damage if one misbehaves. The advisory says that containment does not hold.

The cause is a combination of three things, according to the advisory. ToolHive's default network permission profile sets insecure_allow_all: true, which permits outbound connections to any destination. Docker provides a DNS name, host.docker.internal, that resolves from inside a container to the host machine, defeating the assumption that a service bound to localhost is unreachable. And ToolHive's own API and MCP proxy endpoints carry no authentication, so any client that can reach the port can interact with them fully.

The advisory includes reproduction steps carried out from inside a stock filesystem MCP container started with default settings. In one test, the container completed a full MCP handshake with ToolHive's own control-plane endpoint on the host, which identified itself as toolhive-mcp version v0.9.3. In another, the container connected to a different MCP server's proxy, listed its tools, including read_file, write_file, edit_file and move_file, and successfully called one. The container also reached a Kubernetes API server on port 6443 and an Ollama LLM API on port 11434, returning version and model information in both cases.

The advisory sets out four attack scenarios. The first involves a hostile containerised MCP server port-scanning host.docker.internal, attempting MCP handshakes on whatever it finds, and then calling privileged tools exposed by native, non-containerised MCP servers such as terminal or desktop control tools. The advisory says this would achieve full host compromise without any container escape vulnerability. The second scenario has a compromised container using the unauthenticated ToolHive endpoint to stop other running MCP servers, start new ones from attacker-controlled images, or change configurations. The third is cross-server data access, where a low-privilege server with no file mounts reaches the filesystem server's proxy and reads files it was never authorised to see. The fourth is abuse of self-hosted language models reachable on the host.

The advisory proposes mitigations in three tiers. In the short term it suggests blocking host.docker.internal and the Docker gateway address 172.17.0.1 by default, even when insecure_allow_all is set, and adding a shared secret or per-session token to MCP proxy endpoints. In the medium term it recommends per-container network policies with explicit allow-lists, rather than ToolHive's current binary choice between no network access and all of it, and giving each MCP server its own Docker network with no route to the bridge gateway. Longer term it suggests mutual TLS or token-based authentication between the proxy and containers, plus audit logging of tool calls with source identification so lateral movement attempts are visible.

The testing was done on ToolHive v0.9.3 running as a macOS desktop app with the Docker runtime, using Docker Desktop for Mac, where host.docker.internal is enabled by default. The incident record lists the issue's status as reported.