Most recent entries from all

EUVD-2026-368725

fkie_cve-2026-54450

ToolHive is a utility designed to simplify the deployment and management of Model Context Protocol (MCP) servers. Prior to 0.29.1, networking.IsPrivateIP in pkg/networking/utilities.go omits the IPv6 NAT64 prefixes 64:ff9b::/96 and 64:ff9b:1::/48, so NAT64 addresses embedding private, loopback, or link-local IPv4 targets are classified as public and allowed. The most direct attacker-controlled path begins when an external OAuth client supplies a client_id URL that CIMDStorageDecorator.GetClient routes through FetchClientMetadataDocument in pkg/oauthproto/cimd/fetch.go; protectedDialerControl in pkg/networking/http_client.go and validateHost in pkg/skills/gitresolver/reference.go share the defective classification but use operator-controlled or user-controlled destinations. On a ToolHive host behind a NAT64/DNS64 gateway, the gateway translates an allowed address such as 64:ff9b:1::a9fe:a9fe to 169.254.169.254, permitting blind probing of internal TCP or TLS reachability. The attacker-controlled CIMD path requires HTTPS, verifies certificates, and does not reflect response bodies, so the established impact is an internal reachability oracle rather than metadata credential exfiltration; the webhook client is not affected because it does not use this IP guard. This issue is fixed in version 0.29.1.

GHSA-pph6-vfjv-vpjw — ToolHive: SSRF guard misses IPv6 NAT64 ranges (64:ff9b::/96, 64:ff9b:1::/48), allowing metadata/internal access behind…

Affected: Go: github.com/stacklok/toolhive

## Summary

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 with TLS verification and does not reflect responses) — see Impact.

The most direct attacker-controlled entry point is the embedded OAuth authorization server's Client ID Metadata Document (CIMD) fetcher: an external OAuth client presents `client_id=https://<attacker-domain>/path`, and `CIMDStorageDecorator.GetClient` fetches that URL through the same guard. The same `IsPrivateIP` table is also shared by the `protectedDialerControl` HTTP clients (registry, OIDC discovery, toke…