CVE-2026-47076

Luka w hackney_ssl w bibliotece benoitc hackney polega na nieprawidłowej walidacji certyfikatów. hackney dodaje wywołanie zwrotne partial_chain do każdej konfiguracji verify_peer, które akceptuje dowolny certyfikat w łańcuchu, którego klucz publiczny pasuje do głównego magazynu certifi, nawet gdy połączenie jest przypięte do prywatnego CA. Atakujący w ścieżce może podszyć się pod serwer, jeśli posiada publicznie zaufany certyfikat dla przypiętej nazwy hosta. Problem dotyczy wersji od 1.24.0 przed 4.9.0.

W bibliotece hackney (benoitc) występuje podatność na wyczerpanie zasobów bez ograniczeń — złośliwy serwer HTTP może wyczerpać pamięć klienta przez zbyt duże lub silnie skompresowane ciało odpowiedzi. Funkcje hackney:request/5 i hackney:body/1 zwracają całe ciało odpowiedzi, a nic nie ogranicza buforowania w procesie połączenia; dotyczy wersji od 2.0.0-beta.1 przed 4.9.0.

Podatność na konflikt interpretacji w hackney_url w benoitc hackney pozwala na Server Side Request Forgery poprzez procentowo zakodowany dosłowny adres IPv6 w nawiasach lub dosłowny adres IP z końcową kropką. Host taki jak %5B%3A%3Affff%3A127%2E0%2E0%2E1%5D (dekodujący się do [::ffff:127.0.0.1]) lub 127.0.0.1. nie jest adresem IP dla listy dozwolonych wywołującego zbudowanej na uri_string:parse/1 i inet:parse_address/1, podczas gdy hackney łączy się z adresem, który oznacza. To samo dotyczy celu Location, gdy następuje przekierowanie.

Podatność na niewystarczającą ochronę danych uwierzytelniających w hackney w benoitc hackney pozwala serwerowi przekierowującemu uzyskać dane uwierzytelniające basic_auth i cookie żądania poprzez przekierowanie na ten sam host na inny schemat lub port. Przy włączonym follow_redirect hackney:follow_redirect/10 w src/hackney.erl ponownie wysyła żądanie do celu Location po hackney:maybe_strip_auth_on_redirect/3, które porównywało tylko nazwę hosta bieżącego i przekierowującego URL. Przekierowanie z https na http na tym samym hoście ponownie wysyłało nagłówki Authorization i Cookie w postaci jawnej, gdzie atakujący na ścieżce może je odczytać, a przekierowanie na inny port na tym samym hoście przekazywało je innej usłudze. location_trusted przekazuje dane uwierzytelniające do dowolnego celu zgodnie z projektem i pozostaje bez zmian.

W bibliotece hackney (benoitc) w wersji od 2.0.0 do przed 4.9.0 występuje niewłaściwa neutralizacja sekwencji CRLF w nagłówkach HTTP (HTTP Request/Response Splitting) w hackney_http_connect. Po odpowiedzi 407 od proxy HTTP CONNECT funkcja handle_proxy_auth/11 wywołuje przekazany przez wywołującego proxy_auth_fun i zapisuje zwrócony binarny wynik do linii Proxy-Authorization ponownego żądania CONNECT bez sprawdzenia go; bajt CR, LF lub NUL w tej wartości dodaje linie nagłówka do żądania wysyłanego do proxy.

Podatność w bibliotece hackney (wersje od 2.0.0 do 4.0.1) pozwala na atak typu Flooding przez brak ograniczenia rozmiaru bufora odpowiedzi HTTP/3. Złośliwy serwer może wysyłać małe fragmenty danych, resetując licznik czasu, co prowadzi do nieograniczonego wzrostu pamięci i wyczerpania sterty procesu BEAM.

hackney przed wersją 4.0.1 nie koduje procentowo znaków CR (\r) i LF (\n) w komponencie zapytania URL, co umożliwia atak typu HTTP Request Splitting. Atakujący kontrolujący URL może wstrzyknąć surowe sekwencje CRLF do łańcucha zapytania, co pozwala na dodanie dowolnych nagłówków HTTP lub podział żądania.

Podatność w bibliotece hackney (wersje od 2.0.0 do 4.0.1) pozwala na wyczerpanie pamięci przez atakującego serwer WebSocket. Klient WebSocket nie ogranicza rozmiaru buforów w trzech ścieżkach kodu, co umożliwia atak Flooding.

Podatność CRLF Injection w bibliotece hackney umożliwia atakującemu wstrzyknięcie dowolnych nagłówków HTTP do żądania WebSocket. Brak filtrowania znaków CRLF i NUL w czterech miejscach wstrzyknięcia pozwala na manipulację żądaniem, co może prowadzić do fałszowania poświadczeń, zatrucia pamięci podręcznej lub przemytu żądań przez proxy.

Biblioteka hackney w wersjach od 0.10.0 do 4.0.1 (przed 4.0.1) zawiera podatność na niekontrolowane zużycie zasobów w transporcie SOCKS5. Po zakończeniu negocjacji SOCKS5 połączenie jest uaktualniane do TLS z nieskończonym timeoutem, co pozwala wrogiego proxy na zablokowanie procesu na czas nieokreślony.