CVE-2026-54452
ŚrednieCVSS 6.3Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 33 - wyżej niż 33% wszystkich znanych CVE
Streszczenie
W bibliotece safeurl przed wersją 0.2.4 lista privateNetworks w ip.go pomija zakresy IPv6 64:ff9b:1::/48, 5f00::/16, 3fff::/20 oraz 100:0:0:1::/64. Gdy aplikacja włączy IPv6 poprzez EnableIPv6(true), cel atakującego w jednym z tych zakresów nie jest rozpoznawany jako niepubliczny i może przejść kontrolę SSRF. IPv6 jest domyślnie wyłączony, więc konfiguracje z EnableIPv6(false) nie są narażone.
Ocena ryzyka
Atakujący może obejść ochronę przed SSRF i uzyskać dostęp do zasobów hostowanych w pominiętych zakresach IPv6. Ryzyko dotyczy aplikacji, które jawnie włączyły obsługę IPv6 w bibliotece safeurl.
Rekomendacja
Zaktualizuj bibliotekę safeurl do wersji 0.2.4 lub nowszej. Jeśli aktualizacja nie jest możliwa, pozostaw EnableIPv6(false) lub ręcznie uzupełnij listę prywatnych zakresów IPv6.
Inne podatności w safeurl
Zobacz wszystkie- CVE-2026-77972Krytyczne
Podatność typu Time-of-check Time-of-use (TOCTOU) w Slab safeurl pozwala atakującemu kontrolującemu odpowiedzi DNS hostname na dotarcie do wewnętrznych celów sieciowych, które walidacja odrzuciła. Walidacja zwraca werdykt, a nie adres, który zatwierdziła, więc klienci HTTP dostarczani z biblioteką otrzymują oryginalny hostname i rozwiązują go ponownie przy wysyłaniu żądania. Atakujący kontrolujący autorytatywny DNS dla nazwy może odpowiedzieć na pierwsze zapytanie dozwolonym adresem, a na drugie zablokowanym, przez co żądanie dociera do celu, którego walidacja nigdy nie zatwierdziła. To samo okno otwiera się bez atakującego, gdy nazwa legalnie rozwiązuje się na różne adresy między zapytaniami, np. przy krótkim czasie życia rekordów lub rotacji między kilkoma adresami. Problem dotyczy safeurl od wersji 0.1.0.
- CVE-2026-77866Krytyczne
Podatność Server-Side Request Forgery (SSRF) w Slab safeurl pozwala atakującemu kontrolującemu zwalidowany URL na dotarcie do wewnętrznych celów sieciowych, które biblioteka ma blokować. Tylko adresy IPv4 są dopasowywane do zarezerwowanych zakresów i blocklisty. Każdy inny adres jest traktowany jako niepasujący do niczego, więc cel odrzucony w formie IPv4 jest akceptowany, gdy jest zapisany jako adres IPv6, wpisy IPv6 w blockliście nigdy nie pasują, a host, który nie rozwiązuje się na żaden adres IPv4, jest akceptowany niezależnie od tego, gdzie wskazuje. Wdrożenia opierające się na allowliście są nienaruszone, ponieważ tam niedopasowany adres jest odrzucany. Problem dotyczy safeurl od wersji 0.1.0.
Oryginalny opis (angielski, źródło NVD)
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.

