GHSA-pph6-vfjv-vpjw ToolHive: SSRF guard misses IPv6 NAT64 ranges (64:ff9b::/96, 64:ff9b:1::/48), allowing metadata/internal access behind a NAT64 gateway
SummaryToolHive'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, token introspection) and the skills git-clone host check (`pkg/skills/gitresolver`), though those destinations are operator-/user-configured rather than attacker-controlled. (Note: the webhook client is *not* affected — it enforces only the HTTPS scheme via `ValidatingTransport` and performs no IP-based check.)Details`pkg/networking/utilities.go` builds a `privateIPBlocks` table and `IsPrivateIP`:The table contains no entry for `64:ff9b::/96` or `64:ff9b:1::/48`. A NAT64 address is a normal global-unicast IPv6 address: `net.IP.IsGlobalUnicast()` returns true and it matches none of the listed blocks, so `IsPrivateIP` returns `false`.The CIMD fetcher (`pkg/oauthproto/cimd/fetch.go`, `newCIMDHTTPClient`) is the careful, post-resolution, anti-rebinding path that nonetheless inherits the gap:Because `IsPrivateIP(64:ff9b:1::a9fe:a9fe)` is `false`, the dialer proceeds. In a NAT64 network the kernel's NAT64 gateway transparently translates that IPv6 destination to a connection to `169.254.169.254`.Trust boundary: the CIMD URL originates from the `client_id` of an external OAuth client at authorize/token time (`CIMDStorageDecorator.GetClient` → `IsClientIDMetadataDocumentURL(id)` → `cimd.FetchClientMetadataDocument(ctx, id)`), so it is fully attacker-controlled. The `protectedDialerControl` HTTP clients used for registry, OIDC discovery, and token introspection (`pkg/networking/http_client.go` → `AddressReferencesPrivateIp` → `IsPrivateIP`) and the skills git-clone host check (`pkg/skills/gitresolver/reference.go` `validateHost` → `IsPrivateIP`) share the same table and the same gap, but with operator-/user-supplied targets rather than attacker-controlled ones.Note that `::ffff:169.254.169.254` (IPv4-mapped) is correctly blocked because Go normalizes it to the v4 form; the NAT64 encoding is a distinct, non-normalized IPv6 address and is not caught.AffectedModule: `github.com/stacklok/toolhive`Affected packages/paths: `pkg/networking/utilities.go` (`IsPrivateIP`), reached via `pkg/oauthproto/cimd/fetch.go` (`FetchClientMetadataDocument`, CIMD authorization-server path — the attacker-controlled entry point), `pkg/networking/http_client.go` (`protectedDialerControl`, used by the registry / OIDC-discovery / token-introspection clients), and `pkg/skills/gitresolver/reference.go` (`validateHost`, skills git-clone host check). The webhook client (`pkg/webhook`) is not affected: it validates only the HTTPS scheme and performs no `IsPrivateIP` check.Affected versions: all releases through v0.29.0 (the `IsPrivateIP` table has lacked NAT64 entries since the guard was introduced; the CIMD reach was added in v0.28.1).Precondition for full exploitability: the ToolHive process runs in an environment with a NAT64/DNS64 gateway (e.g. IPv6-only Kubernetes / IPv6-only cloud). The classification defect itself is present unconditionally.Proof of ConceptThe following self-contained Go program imports ToolHive **v0.29.0** (commit `570ce07013b72208fcae339e9492f5867a1af994`) and exercises the real guard code: the exported `networking.IsPrivateIP`, the exported `oauthproto.IsClientIDMetadataDocumentURL` predicate that routes a `client_id` into the CIMD fetch path, and the CIMD dialer gate copied verbatim from `pkg/oauthproto/cimd/fetch.go`. The only modeled elements are the network's DNS64 record (attacker host → NAT64 IPv6) and the kernel NAT64 gateway (final dial → control listener) — the security decision is made entirely by ToolHive's own code.`go.mod`:`main.go`:Output:The attacker-controlled `client_id` host (NAT64-resolved) passes the real `IsPrivateIP` gate and reaches the IMDS stand-in, while the raw metadata address is correctly blocked by the same gate.ImpactServer-Side Request Forgery (CWE-918), **Low**. On a ToolHive deployment behind a NAT64/DNS64 gateway, an attacker who controls a URL reaching the guard can cause ToolHive to attempt connections to internal/link-local addresses the guard is meant to block — RFC1918, loopback, and the link-local metadata address `169.254.169.254` (encoded as `64:ff9b::a9fe:a9fe` / `64:ff9b:1::a9fe:a9fe`).The practical effect is a **blind internal-reachability / SSRF oracle, not data or credential exfiltration.** On the only fully attacker-controlled entry point — the CIMD fetcher — three constraints bound the impact:**HTTPS-only.** `validateCIMDClientURL` rejects non-loopback `http://`, so the dial is TLS. Cloud instance metadata services (AWS/GCP/Azure, all on `169.254.169.254`) serve **plain HTTP on port 80**, so a TLS connection cannot retrieve metadata credentials.**TLS certificate verification.** `newCIMDHTTPClient` sets no custom `TLSClientConfig`; reaching an internal HTTPS service requires a certificate valid for the attacker-supplied host/IP, which an internal service will not present.**No response reflection.** A fetched document must satisfy `ValidateClientMetadataDocument` (its `client_id` must equal the fetched URL) and the body is never returned to the attacker.What remains is the ability to probe whether an internal `host:port` accepts a TCP/TLS connection (via success/timing differences) — internal network reconnaissance, not credential theft.Reachable via:the embedded OAuth authorization server CIMD path — `client_id` URL supplied by an external OAuth client (no pre-registration); HTTPS-only and blind, as above;the registry / OIDC-discovery / token-introspection HTTP clients that share `IsPrivateIP` via `protectedDialerControl` — but those destinations are operator-configured, not attacker-controlled;the skills git-clone host check (`pkg/skills/gitresolver` `validateHost`) — likewise operator-/user-configured, and it only validates literal IPs (a hostname that resolves to a NAT64/private address is not caught there regardless of this defect).Exploitability is conditional on the host's network providing NAT64/DNS64 (e.g. IPv6-only Kubernetes and some IPv6-only cloud setups). The IP-classification defect itself is present unconditionally.Root cause`networking.IsPrivateIP` relies on a manually maintained CIDR list that omits the IPv6 NAT64 transition ranges. NAT64 addresses embed an IPv4 address (`64:ff9b::<v4>` and `64:ff9b:1::<v4>`) and route to it via a NAT64 gateway, so a NAT64 address that embeds a private/link-local IPv4 address is effectively as sensitive as that IPv4 address — but it is a syntactically global-unicast IPv6 address and therefore evades the private-range list and the `IsGlobalUnicast`/`IsLinkLocalUnicast` checks.FixAdd the NAT64 prefixes to the private/reserved set so that NAT64-encoded addresses are classified by the IPv4 address they embed (or, at minimum, rejected outright). Concretely, add `64:ff9b::/96` and `64:ff9b:1::/48` to `privateIPBlocks` in `pkg/networking/utilities.go`; for completeness, when an address falls in a NAT64 prefix, extract the embedded IPv4 (last 32 bits) and apply the existing IPv4 private/reserved checks to it, so that `64:ff9b::8.8.8.8` (a NAT64 path to a genuinely public host) is not over-blocked while `64:ff9b:1::a9fe:a9fe` is blocked. The implemented fix (PR on the private advisory fork) takes this embedded-IPv4 approach: it decodes the low 32 bits for the well-known `64:ff9b::/96` and the `64:ff9b:1::/96` sub-prefix and re-applies the IPv4 private/reserved checks, so genuinely public NAT64 egress is not over-blocked. Because the RFC 8215 local-use `64:ff9b:1::/48` may use a shorter NAT64 prefix (RFC 6052 §2.2) that places the embedded IPv4 outside the low 32 bits, the remainder of that `/48` is blocked wholesale (fail closed) rather than decoded, avoiding a false-negative bypass.As bundled defense-in-depth, the same patch also classifies a few special-use ranges that `IsPrivateIP` previously missed: `0.0.0.0/8` (RFC 1122 "this host") and the unspecified address (`0.0.0.0` / `::`), plus `240.0.0.0/4` (RFC 1112 reserved, including the `255.255.255.255` broadcast). Separately tracked follow-ups (not in this patch): decoding/rejecting other IPv4-in-IPv6 transition ranges (6to4 `2002::/16`, Teredo `2001::/32`, IPv4-compatible `::/96`), and a pre-clone DNS-resolution check in the skills git resolver, which currently validates only literal IPs.ResourcesRFC 6052 — IPv6 Addressing of IPv4/IPv6 Translators (well-known prefix `64:ff9b::/96`)RFC 8215 — Local-Use IPv4/IPv6 Translation Prefix (`64:ff9b:1::/48`)RFC 6147 — DNS64CWE-918 — Server-Side Request Forgery (SSRF)ToolHive v0.29.0, commit `570ce07013b72208fcae339e9492f5867a1af994`
CVSS v4.0 score: 2.9