CVE-2026-54452
MediumCVSS 6.3Exploitation Probability (EPSS)
Low risk33th percentile - higher than 33% of all known CVEs
Summary
In the safeurl 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 via EnableIPv6(true), an attacker-controlled destination in one of these ranges is not recognized as non-public and can pass the SSRF destination check. IPv6 is disabled by default, so configurations with EnableIPv6(false) are not exposed.
Risk Assessment
An attacker can bypass SSRF protection and access resources hosted within the omitted IPv6 ranges. The risk affects applications that explicitly enabled IPv6 support in the safeurl library.
Recommendation
Upgrade the safeurl library to version 0.2.4 or later. If upgrade is not possible, keep EnableIPv6(false) or manually add the missing private IPv6 ranges to the list.
Other vulnerabilities in safeurl
See all- CVE-2026-77972Critical
Time-of-check Time-of-use (TOCTOU) Race Condition in Slab safeurl allows an attacker who controls a hostname's DNS responses to reach internal network destinations that validation rejected. Validation returns a verdict and not the address it approved, so the HTTP clients the library ships receive the original hostname and resolve it a second time when the request is made. An attacker who controls the authoritative DNS for a name can answer the first lookup with a permitted address and the second with a blocked one, and the request then reaches a destination validation never approved. The same window opens without an attacker whenever a name legitimately resolves to different addresses across lookups, such as short record lifetimes or rotation between several addresses. This issue affects safeurl: from 0.1.0 onward.
- CVE-2026-77866Critical
Server-Side Request Forgery (SSRF) vulnerability in Slab safeurl allows an attacker who controls a validated URL to reach internal network destinations the library is configured to block. Only IPv4 addresses are matched against the reserved ranges and the blocklist. Every other address is treated as matching nothing, so a destination that is rejected in its IPv4 form is accepted when written as an IPv6 address, IPv6 entries in the blocklist never match, and a host that resolves to no IPv4 address is accepted regardless of where it points. Deployments that rely on the allowlist instead are unaffected, because there an unmatched address is rejected. This issue affects safeurl: from 0.1.0 onward.
Original NVD description (English source)
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.