ToolHive EUVD-2026-83167

Requires ToolHive CLI prior to 0.30.1 or ToolHive Studio prior to 0.38.0 running MCP servers on a Docker runtime with the DEFAULT (no network isolation) permission profile - for Studio this is aggravated because it explicitly sends network_isolation=false, overriding the backend's secure isolation default. The attacker's foothold is a malicious or compromised MCP server that the operator chooses to run (UI:R); once running, the un-isolated container reaches Docker gateway addresses (host.docker.internal, gateway.docker.internal, 172.17.0.1) and the ToolHive API / MCP proxy endpoints, which are reachable without authentication. Limiting factors: exploitation depends on the operator trusting and launching a hostile MCP server, a Docker deployment, and the pre-0.30.1/0.38.0 default config; environments that already enabled network isolation or that don't run untrusted MCP servers are not realistically exposed.

The vendor CVSS 3.1 vector (AV:A/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H = 8.8) rates this High/Critical, and the mechanics support serious impact: a malicious or compromised MCP server run under a vulnerable ToolHive gets, by default, an un-isolated container network that can reach the Docker gateway (host.docker.internal / gateway.docker.internal / 172.17.0.1) and, crucially, ToolHive's own API and MCP proxy endpoints which are reachable WITHOUT authentication - yielding data/log exposure, invocation of sibling MCP tools, workload-state tampering, and service disruption (justifying C:H/I:H/A:H and the S:C scope change from container to control plane). However, no exploitation-probability signals reinforce the raw score: EPSS is not provided, the CVE is not in CISA KEV, and no public PoC is referenced - so per available data this is 'no public exploit identified at time of analysis,' not active exploitation. The single most important limiting factor is UI:R: exploitation presupposes that the operator actually runs a hostile/compromised MCP server, so realistic risk is dominated by MCP-server supply-chain trust rather than opportunistic remote attack. I differ from the vendor on attack vector: the primary precondition is running a container on the host, which reads more like AV:L than AV:A (the Docker bridge is 'adjacent' only in a loose sense) - verify with the vendor. Net: a genuine and well-understood design weakness worth prompt patching for anyone running untrusted MCP servers, but its low deployment footprint and dependence on user action make it a targeted/insider-trust risk rather than a mass-exploitation priority.

An operator adds and runs a malicious (or later-compromised) MCP server image under an unpatched ToolHive CLI (<0.30.1) or ToolHive Studio (<0.38.0), where network isolation is off by default (Studio even sends network_isolation=false, overriding the backend's secure default). The container uses the Docker gateway to reach the unauthenticated ToolHive API and sibling MCP proxy endpoints, reading data/logs, invoking other MCP tools, and altering workload state without ever escaping the container. No public PoC is referenced, but the fix PRs (toolhive#5583, toolhive-studio#2469) publicly document the exact default-isolation and Docker-gateway behavior.