CVE-2026-54452 in safeurl
Summary
by MITRE • 09/14/2026
safeurl is a server-side request forgery protection library. Prior to 0.2.4, the privateNetworks list in ip.go omits the IPv6 ranges 64:ff9b:1::/48, 5f00::/16, 3fff::/20, and 100:0:0:1::/64. When an application enables IPv6 with EnableIPv6(true), an attacker-controlled destination in one of these ranges is not recognized as non-public and can pass the SSRF destination check, potentially allowing access to resources hosted within the omitted ranges. IPv6 is disabled by default, and configurations that retain EnableIPv6(false) are not exposed to this bypass. This issue is fixed in version 0.2.4.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability identified in safeurl versions prior to 0.2.4 represents a critical server-side request forgery (SSRF) mitigation failure stemming from incomplete IPv6 address classification logic. Safeurl functions as a security library designed to prevent SSRF attacks by validating destination URLs and ensuring they do not resolve to private, local, or otherwise restricted network ranges. The core technical flaw lies within the ip.go module, specifically in the implementation of the privateNetworks list which serves as the whitelist for blocked addresses. This list failed to include several specific IPv6 address blocks that are designated by IANA for special use and should be treated as non-public. These omitted ranges include 64:ff9b:1::/48, which is used for IPv4-IPv6 translation; 5f00::/16, reserved for Teredo tunneling; 3fff::/20, often associated with native IPv6 deployments in certain regions but generally considered non-public or restricted in security contexts; and 100:0:0:1::/64, which is part of the CGNAT (Carrier-Grade NAT) address space. By excluding these prefixes from the blocking list, the library incorrectly classifies traffic destined for these ranges as public internet addresses, thereby allowing them to bypass SSRF protections.
The operational impact of this vulnerability is significant when applications are configured to support IPv6 connectivity. When an application initializes safeurl with EnableIPv6 set to true, it explicitly opts into handling IPv6 destinations through the library's validation logic. In this state, if a user-controlled input directs a request toward any IP address within one of the four omitted ranges, the SSRF check will erroneously pass. This allows attackers to craft malicious requests that target internal services or infrastructure components reachable via these specific IPv6 pathways. For instance, an attacker could potentially access internal APIs, database ports, or management interfaces hosted on servers with addresses in the CGNAT range 100:0:0:1::/64 or other reserved blocks. This bypass effectively undermines the security boundary intended by the SSRF protection mechanism, leading to unauthorized data exposure or further exploitation of backend systems that are assumed to be isolated from direct internet access.
It is crucial to note that this vulnerability is conditional on configuration settings rather than being a universal flaw in all deployments. IPv6 support is disabled by default within safeurl, meaning applications using the standard default configuration with EnableIPv6 set to false remain unaffected as they do not process or validate IPv6 addresses through this specific code path. Consequently, organizations must audit their usage of the library and specifically check for any explicit enabling of IPv6 validation logic. If such a configuration is present in production environments, the risk profile increases substantially due to the potential for remote exploitation via SSRF vectors that leverage these unblocked IPv6 ranges.
To mitigate this vulnerability, immediate remediation involves upgrading safeurl to version 0.2.4 or later, where the privateNetworks list has been corrected to include all relevant reserved and non-public IPv6 prefixes as per industry standards such as RFC 4193 for Unique Local Addresses and other IANA special-purpose registries. This update ensures that traffic destined for these ranges is correctly identified and blocked by the SSRF filter. For applications where upgrading is not immediately feasible, a temporary mitigation involves explicitly disabling IPv6 validation if it is currently enabled but unnecessary for the application's functionality. Additionally, developers should implement defense-in-depth strategies by validating inputs at multiple layers of the stack rather than relying solely on library-level checks, and ensuring that network firewalls restrict outbound connections to only necessary destinations regardless of SSRF protections in place. This vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF) flaws related to insufficient validation of user-supplied URLs against private address spaces, and it can be exploited via techniques documented in the MITRE ATT&CK framework under T1572 Protocol Tunneling or general SSRF exploitation patterns where attackers redirect requests to internal resources.