CVE-2026-54450
ToolHive: SSRF guard misses IPv6 NAT64 ranges (64:ff9b::/96, 64:ff9b:1::/48), allowing metadata/internal access behind a NAT64 gateway
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.
| CWE | CWE-918 |
| Vendor | stacklok |
| Product | toolhive |
| Published | Sep 15, 2026 |
| Last Updated | Sep 15, 2026 |
Get instant alerts for stacklok toolhive
Be the first to know when new unknown vulnerabilities affecting stacklok toolhive are published โ delivered to Slack, Telegram or Discord.