CVE-2026-47073
WysokieCVSS 7.5Prawdopodobieństwo exploitacji (EPSS)
Podwyższone ryzykoPercentyl 54 - wyżej niż 54% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Atakujący może doprowadzić do odmowy usługi (DoS) poprzez wyczerpanie pamięci procesu klienta hackney, bez potrzeby uwierzytelniania.
Rekomendacja
Zaktualizuj bibliotekę hackney do wersji 4.0.1 lub nowszej.
Inne podatności w hackney
Zobacz wszystkie- CVE-2026-47077Wysokie
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.
- CVE-2026-47076Średnie
Biblioteka hackney dla Erlanga/OTP w wersjach od 0.13.0 do 4.0.1 zawiera podatność na fałszowanie żądań po stronie serwera (SSRF) spowodowaną konfliktem interpretacji. Funkcja normalizująca URL dekoduje host po walidacji, co pozwala na ominięcie list dozwolonych i dostęp do wewnętrznych adresów IP (np. 127.0.0.1, 169.254.169.254).
- CVE-2026-47075Wysokie
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.
- CVE-2026-47072Wysokie
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.
- CVE-2026-47071Wysokie
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.
- CVE-2026-47070Średnie
Biblioteka hackney w wersjach od 3.1.1 przed 4.0.1 zawiera podatność na wyciek danych wrażliwych. Moduł HTTP/3 (hackney_h3.erl) nie sprawdza pochodzenia przy przekierowaniach, przez co nagłówki autoryzacyjne i ciasteczka są wysyłane do obcych hostów.
- CVE-2026-47069Średnie
W bibliotece hackney (wersje od 0.9.0 przed 4.0.1) stwierdzono podatność na CRLF Injection w funkcji hackney_cookie:setcookie/3. Atakujący kontrolujący opcję domain lub path może wstrzyknąć sekwencję CRLF i dowolne nagłówki Set-Cookie, co prowadzi do HTTP Response Splitting.
- CVE-2026-47067Wysokie
Biblioteka hackney w wersjach od 2.0.0 do 4.0.1 (przed 4.0.1) zawiera podatność na wyczerpanie tablicy atomów BEAM. Parser URL konwertuje nierozpoznane schematy URL na atomy za pomocą binary_to_atom/2, które nigdy nie są usuwane. Atakujący może dostarczyć wiele URL-i z unikalnymi schematami, powodując przekroczenie limitu tablicy atomów i awarię całej maszyny wirtualnej BEAM.
- CVE-2026-47066Wysokie
Biblioteka hackney w wersjach od 2.0.0-beta.1 do 4.0.1 (przed 4.0.1) zawiera podatność na nieskończoną pętlę w parserze nagłówka Alt-Svc. Funkcja parse_token/2 nie zapewnia postępu dla niektórych bajtów, co prowadzi do rekurencyjnej pętli zajmującej 100% CPU. Nagłówek Alt-Svc: ! jest wystarczający do wywołania podatności.
Oryginalny opis (angielski, źródło NVD)
Allocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. The WebSocket client in src/hackney_ws.erl imposes no upper bound on memory consumption in three code paths. First, read_handshake_response/3 accumulates received bytes into a growing buffer with no size cap; the per-receive timeout resets on every chunk, so a server that streams bytes without ever sending \r\n\r\n causes the buffer to grow until memory is exhausted. Second, parse_payload/9 and parse_active_payload/8 do not validate the declared frame payload length against any limit; because RFC 6455 allows payload lengths up to 2^63-1 bytes, a server that announces a very large frame and dribbles bytes causes the accumulation buffer to grow until OOM. Third, the frag_buffer field in #ws_data{} accumulates continuation frames indefinitely; a server that sends an endless stream of non-final (nofin) fragmented frames without ever sending a final (fin) frame grows frag_buffer without bound. In all three cases the attacker only needs to control the WebSocket server the hackney client connects to, with no authentication or special client configuration required. This issue affects hackney: from 2.0.0 before 4.0.1.