CVE-2026-114216

W bibliotece bandit (Elixir) w wersjach od 0.3.1 przed 1.14.1 czytnik ciała żądania HTTP/2 nie ogranicza zasobów, co pozwala nieuwierzytelnionemu zdalnemu atakującemu wyczerpać pamięć serwera poprzez ciało żądania wysłane jako wiele ramek DATA o rozmiarze 1 bajta. Podatne są trasy, których Plug odczytuje ciało żądania, w tym trasy za Plug.Parsers.

W bibliotece bandit (mtrudel) występuje podatność na wyczerpanie zasobów bez ograniczeń w czytniku ciała żądania HTTP/2 — nieuwierzytelniony zdalny atakujący może utrzymywać procesy strumieni otwarte bezterminowo przez ramki WINDOW_UPDATE lub puste SETTINGS wysyłane podczas gdy Plug czyta ciało żądania. Dotyczy wersji od 1.4.0 przed 1.14.0.

Podatność w bibliotece Bandit (Elixir) polega na braku limitu liczby fragmentów wiadomości WebSocket podczas ich łączenia. Atakujący może wysłać wiadomość złożoną z wielu 1-bajtowych ramek kontynuacji, co powoduje zużycie pamięci serwera znacznie przekraczające skonfigurowany limit (nawet 150-krotnie).

Podatność w parserze liczb całkowitych nagłówków HTTP w bibliotece Bandit (Elixir) pozwala nieuwierzytelnionemu atakującemu na zużycie CPU serwera poprzez przesłanie wartości Content-Length, Host lub portu :authority składającej się z tysięcy cyfr. Parsowanie odbywa się bez limitu długości, co prowadzi do kwadratowego wzrostu czasu przetwarzania.

Podatność w obsłudze HTTP/2 w bibliotece Bandit (Elixir) polega na nieprawidłowym czyszczeniu stanu po wyjątku StreamError. Atakujący może obejść limity zasobów na połączenie, wysyłając wiele ramek w jednym zapisie TCP, z których jedna powoduje błąd strumienia, co prowadzi do uruchomienia większej liczby równoległych strumieni niż dozwolona.

Podatność w czytniku ciała żądania chunked w HTTP/1.1 w bibliotece Bandit (Elixir) pozwala nieuwierzytelnionemu atakującemu na wyczerpanie pamięci i CPU serwera poprzez żądanie złożone z wielu 1-bajtowych fragmentów. Brak limitu liczby fragmentów powoduje, że małe fragmenty zużywają znacznie więcej pamięci niż ich ładunek.

Podatność w implementacji HTTP/2 w bibliotece Bandit (Elixir) pozwala nieuwierzytelnionemu atakującemu na nieograniczony wzrost zużycia pamięci i CPU poprzez dużą wartość SETTINGS_HEADER_TABLE_SIZE. Bandit zmienia rozmiar tabeli kodera HPACK do rozmiaru ogłoszonego przez klienta (do 2^32-1 bajtów) i indeksuje nagłówki odpowiedzi, co prowadzi do liniowego skanowania przy każdym wyszukaniu i kwadratowego wzrostu kosztu CPU.

Podatność na egzekwowanie zabezpieczeń po stronie klienta zamiast serwera w obsłudze połączeń WebSocket w mtrudel bandit pozwala zdalnemu klientowi na dalsze uruchamianie kodu obsługi WebSock po zatrzymaniu połączenia przez serwer, poprzez ramki danych wysyłane po zignorowaniu ramki Close serwera. Gdy callback WebSock zwraca {:stop, ...}, Bandit.WebSocket.Connection wywołuje terminate/2, wysyła Close i zamyka stronę zapisu, ale utrzymuje proces połączenia w stanie :closing. handle_frame/3 i handle_info/3 nigdy nie sprawdzają tego stanu, więc późniejsze ramki nadal docierają do handle_in/2, a późniejsze wiadomości do handle_info/2, ze stanem z krotki stop, dopóki klient nie wyśle Close, TCP nie zostanie zerwane lub nie upłynie limit czasu bezczynności. Klient odrzucony w init/1 po nieudanym sprawdzeniu tokena mógłby nadal wykonać akcję tylko dla administratora.

Podatność w implementacji HTTP/2 w bibliotece Bandit (Elixir) polega na nieprawidłowym przetwarzaniu silnie skompresowanych danych (amplifikacja danych). Atakujący może wysłać mały blok HEADERS skompresowany HPACK, który przechowuje dużą wartość cookie w tabeli dynamicznej, a następnie wielokrotnie odwołuje się do niej za pomocą 1-bajtowych pól indeksowanych, co prowadzi do wyczerpania pamięci serwera.

Podatność w implementacji HTTP/2 w bibliotece Bandit (Elixir) polega na nieefektywnej złożoności algorytmicznej. Atakujący może otworzyć tysiące strumieni, których odpowiedzi są zablokowane, a następnie wysyłać tanie ramki SETTINGS lub WINDOW_UPDATE, powodując kwadratowy wzrost kosztu CPU przy przetwarzaniu kolejki zablokowanych wysyłek.