Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
HTTP/2 Bomb to nowo opisana technika zdalnego ataku typu denial-of-service, wymierzona w implementacje protokołu HTTP/2 stosowane w popularnych serwerach WWW, reverse proxy i komponentach edge. Istota problemu polega na wykorzystaniu sposobu przetwarzania skompresowanych nagłówków, ramek protokołu oraz mechanizmów buforowania po stronie serwera.
W praktyce atakujący może doprowadzić do nadmiernego zużycia pamięci lub CPU przy relatywnie niewielkim koszcie własnym. To sprawia, że zagrożenie jest szczególnie poważne dla publicznie dostępnych usług, które akceptują połączenia HTTP/2 i obsługują duży ruch aplikacyjny.
W skrócie
HTTP/2 Bomb wykorzystuje asymetrię kosztów między klientem a serwerem. Niewielka ilość odpowiednio przygotowanego ruchu może wywołać po stronie celu kosztowne operacje dekodowania, rekonstrukcji bloków nagłówków i alokacji pamięci.
- Atak może dotyczyć szeroko używanych komponentów, takich jak NGINX, Apache HTTP Server, Microsoft IIS, Envoy oraz Pingora.
- Nie wymaga klasycznego wolumetrycznego DDoS ani dużego botnetu.
- Może być trudniejszy do wykrycia, ponieważ ruch sieciowy nie musi wyglądać na wyjątkowo intensywny.
- Największym ryzykiem jest utrata dostępności usług oraz degradacja wydajności warstwy frontowej.
Kontekst / historia
Zainteresowanie bezpieczeństwem HTTP/2 nie jest nowe. W ostatnich latach protokół był już przedmiotem analiz pod kątem asymetrycznych ataków DoS, w których przeciwnik nie przeciąża łącza, lecz logikę parsera i mechanizmy obsługi sesji.
Głośnym przykładem był Rapid Reset, który pokazał, że poprawne formalnie zachowanie klienta może generować bardzo wysoki koszt po stronie infrastruktury. Później szeroko komentowano również klasę błędów CONTINUATION Flood, wskazującą na ryzyko związane z obsługą ramek HEADERS i CONTINUATION oraz zbyt późnym egzekwowaniem limitów.
HTTP/2 Bomb wpisuje się w ten sam trend. To kolejna ewolucja ataków skupionych na ekonomii przetwarzania protokołu, kompresji nagłówków i buforowaniu danych, a nie na samej przepustowości sieci.
Analiza techniczna
HTTP/2 przesyła nagłówki w postaci binarnych ramek i wykorzystuje mechanizm HPACK do ich kompresji. Dzięki temu mały blok wejściowy może po stronie serwera prowadzić do znacznie większego kosztu obliczeniowego lub pamięciowego. W zależności od implementacji serwer może rekonstruować pełny blok nagłówków przed przekazaniem go do dalszej warstwy aplikacyjnej, co zwiększa powierzchnię ataku.
W scenariuszu określanym jako HTTP/2 Bomb napastnik wykorzystuje właściwości kompresji, fragmentacji nagłówków i kolejności przetwarzania ramek, aby uzyskać skrajnie niekorzystny stosunek kosztów. Dla klienta transmisja pozostaje tania, natomiast po stronie ofiary rośnie koszt dekodowania, buforowania i walidacji.
Jeżeli implementacja nie nakłada odpowiednich limitów na rozmiar nagłówków, liczbę ramek, czas kompletowania bloku lub liczbę aktywnych strumieni, skutkiem może być szybkie wyczerpanie zasobów. W zależności od produktu objawy mogą obejmować skoki zużycia pamięci, intensywne użycie CPU, wzrost opóźnień, błędy 5xx albo restart procesu.
To odróżnia HTTP/2 Bomb od klasycznego floodu sieciowego. Atak nie wymaga ogromnego wolumenu pakietów, ponieważ jego skuteczność wynika z kosztowności przetwarzania po stronie serwera. Dodatkowym problemem jest ograniczona widoczność w standardowych logach dostępowych, ponieważ przeciążenie może powstawać jeszcze przed pełną obsługą żądania na poziomie aplikacji.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją jest utrata dostępności usługi. Jeśli podatny komponent pełni rolę frontowego reverse proxy, load balancera lub gatewaya API, awaria jednego elementu może przełożyć się na niedostępność wielu aplikacji jednocześnie.
Ryzyko operacyjne jest wysokie z kilku powodów. Po pierwsze, atak zwykle nie wymaga uwierzytelnienia. Po drugie, może być przeprowadzony z niewielkiej liczby źródeł, więc klasyczne mechanizmy obrony przed DDoS oparte wyłącznie na wolumenie ruchu mogą nie zareagować wystarczająco szybko. Po trzecie, podatne komponenty często znajdują się w krytycznej warstwie wejściowej infrastruktury.
- degradacja SLA i wzrost opóźnień,
- błędy aplikacyjne i resetowanie połączeń,
- zakłócenie usług B2B i paneli administracyjnych,
- ryzyko wykorzystania incydentu jako zasłony dymnej dla innych działań przeciwnika.
Rekomendacje
Organizacje powinny w pierwszej kolejności ustalić, które systemy publicznie wystawione akceptują ruch HTTP/2 i gdzie następuje terminacja połączeń. Dotyczy to serwerów WWW, gatewayów API, środowisk gRPC, service mesh, platform CDN oraz warstwy edge.
- śledzić komunikaty producentów i projekty upstream dotyczące poprawek oraz obejść,
- wdrażać aktualizacje bezpieczeństwa bez zbędnej zwłoki,
- czasowo ograniczyć lub wyłączyć HTTP/2 tam, gdzie nie jest niezbędny,
- zweryfikować limity rozmiaru nagłówków, liczby ramek i liczby współbieżnych strumieni,
- ustawić bardziej restrykcyjne timeouty dla odbioru i kompletowania nagłówków,
- włączyć telemetrię warstwy HTTP/2, a nie polegać wyłącznie na access logach,
- monitorować anomalie dotyczące HEADERS, CONTINUATION, pamięci i CPU,
- stosować ochronę edge, WAF lub proxy egzekwujące limity protokołowe przed backendem,
- przeprowadzić testy odporności uwzględniające asymetryczne scenariusze DoS.
W środowiskach o wysokiej krytyczności warto przygotować plan kontrolowanej degradacji. Może on obejmować przełączenie części usług na HTTP/1.1, ograniczenie współbieżności, ostrzejsze limity zasobów i automatyczne blokowanie źródeł generujących nietypowe sekwencje ramek.
Podsumowanie
HTTP/2 Bomb pokazuje, że nowoczesne ataki na dostępność coraz częściej wykorzystują nie przepustowość, lecz koszt przetwarzania protokołu. Dla zespołów bezpieczeństwa, administratorów i SRE to wyraźny sygnał, że ochrona przed DoS musi obejmować również parsery, kompresję nagłówków, limity zasobów i widoczność na poziomie warstwy aplikacyjnej.
W praktyce oznacza to konieczność regularnego hardeningu usług korzystających z HTTP/2. Każda implementacja, która kosztownie dekoduje nagłówki lub buforuje dane bez ścisłych ograniczeń, może stać się celem skutecznego ataku na dostępność.
Źródła
- The Hacker News — https://thehackernews.com/2026/06/new-http2-bomb-vulnerability-allows.html
- Bartek Nowotarski — HTTP/2 CONTINUATION Flood: Technical Details — https://nowotarski.info/http2-continuation-flood-technical-details/
- CERT/CC VU#421644 — HTTP/2 CONTINUATION frames can be utilized for DoS attacks — https://kb.cert.org/vuls/id/421644
- GitLab Advisory Database — CVE-2026-33871: Netty HTTP/2 CONTINUATION Frame Flood DoS via Zero-Byte Frame Bypass — https://advisories.gitlab.com/pkg/maven/io.netty/netty-codec-http2/CVE-2026-33871/
- GitHub Advisory Database — CVE-2023-44487 HTTP/2 Stream Cancellation Attack — https://github.com/advisories/GHSA-qppj-fm5r-hxr3