CVE-2026-55473: HomeBox: Notifier SSRF guard misses NAT64 prefixes (64:ff9b::/96, 64:ff9b:1::/48) — generic:// URL reaches cloud metadata on NAT64 egress
HomeBox is a home inventory and organization system. Prior to 0.26.0, the default-on BlockBogonNets and BlockCloudMetadata notifier SSRF protections in backend/internal/sys/validate/notifierurl.go do not inspect IPv4 destinations embedded in the NAT64 prefixes 64:ff9b::/96 and 64:ff9b:1::/48. An authenticated user can submit a generic:// notifier through POST /v1/notifiers or POST /v1/notifiers/test, and on a Homebox instance that egresses through NAT64/DNS64, the gateway can translate an accepted IPv6 destination to cloud metadata, localhost, or another internal IPv4 host. The notifier test path returns delivery result information, and Shoutrrr propagates the response, providing feedback that can disclose retrieved metadata such as temporary credentials. Without NAT64 egress, the crafted IPv6 destination is not routable, but the guard still incorrectly classifies it as safe. This issue is fixed in version 0.26.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
HomeBoxto a version that resolves this vulnerability.Fixed in 0.26.0
Event History
Frequently Asked Questions
Which deployments are practically exposed to metadata or internal-network access?
Instances running a version before 0.26.0 are practically exposed when their outbound traffic uses NAT64/DNS64. In that environment, NAT64-prefixed IPv6 destinations can be translated to cloud metadata, localhost, or other internal IPv4 hosts.
What level of access does an attacker need?
An attacker must be authenticated and able to submit a generic:// notifier through POST /v1/notifiers or POST /v1/notifiers/test. The test endpoint returns delivery-result information, and propagated responses may disclose retrieved metadata, including temporary credentials.
Are the default SSRF protections sufficient?
No. BlockBogonNets and BlockCloudMetadata are enabled by default but, before 0.26.0, do not inspect IPv4 addresses embedded in 64:ff9b::/96 or 64:ff9b:1::/48 NAT64 prefixes.
What can be done if upgrading is not immediately possible?
Prevent untrusted authenticated users from creating or testing generic:// notifiers, particularly through the notifier creation and test endpoints. Removing or avoiding NAT64/DNS64 egress also prevents the crafted IPv6 destination from being routable, although the URL guard will still classify it as safe.