CVE-2026-120316

http4k w wersjach od 4.9.10.0 przed 6.60.0.0 zawiera podatność braku kontroli integralności, ponieważ DigestEncoder oblicza skrót auth-int bez hashowania treści żądania. Atakujący w kanale (on-path) na kanałach bez TLS mogą zmienić treść uwierzytelnionych żądań, zachowując ważny nagłówek Authorization, i wykonywać akcje zmieniające stan w imieniu ofiary.

http4k to funkcjonalny zestaw narzędzi dla aplikacji HTTP w Kotlinie. W wersjach przed 6.50.0.0 występowała potencjalna podatność XXE (XML External Entity Injection), która mogła umożliwić atakującym odczyt lokalnych informacji wrażliwych na serwerze oraz wywołanie ataków SSRF i wykonanie kodu w określonych okolicznościach.

Moduł uwierzytelniania Digest w http4k (org.http4k:http4k-security-digest) przed wersjami 6.48.0.0, 5.42.0.0 i 4.51.0.0 domyślnie ustawia parametr nonceVerifier w ServerFilters.DigestAuth i DigestAuthProvider na { true }, więc każdy nonce jest akceptowany niezależnie od jego wartości, wieku lub wcześniejszego użycia. Aplikacje korzystające z tego domyślnego ustawienia nie mają ochrony przed powtórzeniem ataku na uwierzytelnianie Digest: atakujący, który przechwyci prawidłową odpowiedź 'Authorization: Digest' (np. obserwując ruch sieciowy lub czytając logi), może ją powtarzać w nieskończoność przeciwko temu samemu chronionemu zasobowi.

http4k (artefakt Maven org.http4k:http4k-core) przed wersjami 6.48.0.0, 5.42.0.0 i 4.51.0.0 zawiera BasicCookieStorage, który nie egzekwuje zasad zakresu RFC 6265 dla domeny, ścieżki i atrybutów Secure. Gdy jedna instancja BasicCookieStorage jest używana do komunikacji z więcej niż jednym origin lub schematem, ciasteczka zapisane dla jednego origin mogą być wysyłane do innych, a ciasteczka oznaczone jako Secure mogą być wysyłane przez zwykły HTTP, co może ujawnić ciasteczka sesji lub inne wrażliwe dane nieautoryzowanym hostom lub obserwatorom sieci.

http4k (pakiet Maven org.http4k:http4k-core) przed wersjami 6.49.0.0, 5.42.0.0 i 4.51.0.0 używa domyślnie dopasowania podciągu (Contains) na nagłówku Host w funkcjach reverseProxy() i reverseProxyRouting() podczas kierowania do skonfigurowanych wirtualnych hostów. Jeśli te funkcje są wdrożone jako publiczny przychodzący handler HTTP z dwoma lub więcej skonfigurowanymi wirtualnymi hostami, zdalny atakujący może dostarczyć nagłówek Host, który jedynie zawiera skonfigurowaną nazwę vhost (np. Host: admin.evil.com dla vhost skonfigurowanego jako "admin") i zostać przekierowany do tego vhost, omijając autoryzację opartą na routingu.

http4k to funkcjonalny zestaw narzędzi dla aplikacji HTTP w języku Kotlin. Przed wersjami 4.51.0.0, 5.42.0.0 i 6.50.0.0, funkcja DigestAuthProvider.verify w http4k-security-digest nie porównuje parametru uri w odpowiedzi Authorization: Digest z rzeczywistym adresem URL żądania. Atakujący, który przechwyci prawidłową odpowiedź uwierzytelniania Digest, może ją powtórzyć wobec innego adresu URL obsługiwanego przez tę samą domenę (realm), omijając powiązanie z URI żądania i potencjalnie uzyskując nieautoryzowany dostęp do odczytu lub zapisu. Problem naprawiono w wersjach 4.51.0.0, 5.42.0.0 i 6.50.0.0.

W http4k przed wersjami 4.51.0.0, 5.42.0.0 i 6.50.0.0 funkcja DigestAuthProvider.verify w http4k-security-digest ignoruje skonfigurowany parametr algorytmu i weryfikuje każdą odpowiedź Digest przy użyciu zakodowanego na stałe MD5. Wdrożenia skonfigurowane dla SHA-256 otrzymują słabszą weryfikację opartą na MD5.

W http4k przed 4.51.0.0, 5.42.0.0 i 6.49.0.0 filtry ServerFilters.GZip, RequestFilters.GunZip oraz podstawowe funkcje dekompresji treści żądania Gzip nie nakładają limitu na rozmiar po dekompresji. Nieuwierzytelniony klient może wysłać małe ciało żądania zakodowane w gzip, które rozszerza się do gigabajtów, wyczerpując stertę JVM.