CVE-2026-111103
WysokieCVSS 8.2Prawdopodobieństwo exploitacji (EPSS)
Podwyższone ryzykoPercentyl 50 - wyżej niż 50% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Nieuwierzytelniony atakujący może obejść limity współbieżnych strumieni i żądań, przeciążając serwer i powodując odmowę usługi.
Rekomendacja
Zaktualizuj bibliotekę Bandit do wersji 1.14.0 lub nowszej, która zawiera poprawkę prawidłowego czyszczenia stanu po wyjątku.
Inne podatności w Bandit
Zobacz wszystkie- CVE-2026-116078Wysokie
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.
- CVE-2026-115269Wysokie
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.
- CVE-2026-114216Średnie
Podatność na niespójną interpretację żądań HTTP ('HTTP Request/Response Smuggling') w czytniku treści chunked HTTP/1.1 w mtrudel bandit pozwala nieuwierzytelnionemu zdalnemu atakującemu na przemycenie drugiego żądania obok front-endowego proxy poprzez rozszerzenie chunka zawierające samo LF. Czytnik chunked w lib/bandit/http1/socket.ex traktuje linię rozmiaru chunka jako wszystko do pierwszego CRLF i odrzuca wszystko po ; bez sprawdzania zgodności z gramatyką chunk-ext RFC 9112, więc samo LF, samo CR i inne bajty kontrolne przechodzą. Proxy, które kończy linię rozmiaru na samym LF, odczytuje 2;\nxx\r\n40\r\n... jako jedno żądanie, którego drugi chunk zawiera GET /admin, podczas gdy Bandit kończy treść wcześniej i wysyła GET /admin jako osobne żądanie potokowe. Wdrożenia bez takiego proxy przed Bandit nie są dotknięte.
- CVE-2026-114213Wysokie
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).
- CVE-2026-113436Wysokie
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.
- CVE-2026-111101Wysokie
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.
- CVE-2026-110499Wysokie
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.
- CVE-2026-110314Średnie
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.
- CVE-2026-109584Wysokie
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.
- CVE-2026-108529Wysokie
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.
Oryginalny opis (angielski, źródło NVD)
Improper Cleanup on Thrown Exception vulnerability in the HTTP/2 handler of mtrudel bandit allows an unauthenticated remote attacker to bypass per-connection resource limits via a single TCP write that carries several frames, one of which raises a stream error. When a frame raises StreamError partway through a chunk, Bandit.HTTP2.Handler.handle_data/3 sends RST_STREAM and continues with the connection state from before the chunk, dropping the rest of it. Streams opened by earlier frames in the chunk keep running their Plug calls, but the stream counts, last_stream_id, the rapid-reset timestamps, the HPACK decoder state and the buffer roll back, so max_concurrent_streams, max_requests and the rapid-reset limiter never see those streams. A client that sends one HEADERS frame more than max_concurrent_streams in each write has the extra refused and the others forgotten: with a limit of 10, five such writes run 50 Plug calls at once. This issue affects bandit: from 1.9.0 before 1.14.0.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

