Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A containerized MCP server running with the default network permission profile (insecureallowall: 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 Result: Full MCP handshake succeeds: 2. Container can connect to another MCP server's proxy and call its tools Result: Returns the full tool list of the target MCP…
Recommended action: Upgrade to 0.30.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Security Advisory: SSRF in remote MCP server authentication discovery Severity: High. CWE: CWE-918. Affected: ToolHive through the latest release v0.29.3 and current main (HEAD b672d82f, 2026-06-12; re-verified 2026-06-14). FetchResourceMetadata and the discovery clients remain unguarded; no commits to pkg/auth/discovery or pkg/auth/remote address this. Originally identified at commit 05f11b53; all line references below are against HEAD b672d82f. Summary ToolHive's remote MCP server authentication discovery issues outbound HTTP requests to URLs the remote MCP server controls, with no private-IP or loopback guard and no restriction on redirects. ToolHive's core security model treats every MCP server as untrusted: the README states it "runs every MCP server in an isolated container" with "no local credentials," and it ships an egress proxy for network isolation. This discovery code runs host-side, in the ToolHive process, before and outside that per-server container sandbox. A…
Recommended action: Upgrade to 0.31.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ToolHive's hand-rolled private/reserved-IP SSRF guard (networking.IsPrivateIP in pkg/networking/utilities.go) does not recognize the IPv6 NAT64 address ranges — the well-known prefix 64:ff9b::/96 (RFC 6052) and the RFC 8215 local-use prefix 64:ff9b:1::/48. As a result, an address such as 64:ff9b:1::a9fe:a9fe — the NAT64 encoding of the link-local cloud metadata address 169.254.169.254 — is classified as a public, global-unicast address and the connection is allowed. On any ToolHive deployment that sits behind a NAT64/DNS64 gateway (the default networking stack in IPv6-only Kubernetes clusters and several IPv6-only cloud environments), an attacker who controls a URL that reaches this guard can have ToolHive attempt connections to internal/link-local addresses that the guard is meant to block, bypassing the SSRF protection. In practice the effect is a blind internal-reachability probe rather than metadata-credential theft (the only fully attacker-controlled path is HTTPS-only…
Recommended action: Upgrade to 0.29.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.