Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
HTTP/2 Bomb to nowo ujawniona technika odmowy usługi, oznaczona jako CVE-2026-49975, która wykorzystuje legalne mechanizmy protokołu HTTP/2 do gwałtownego wyczerpywania pamięci serwera. Nie jest to klasyczny atak oparty na ogromnym wolumenie ruchu, lecz metoda prowadząca do nieproporcjonalnie wysokiego zużycia zasobów po stronie usługi. W efekcie nawet relatywnie niewielkie możliwości techniczne napastnika mogą wystarczyć do zakłócenia działania podatnych systemów.
W skrócie
Nowa technika uderza w implementacje popularnych serwerów WWW i proxy obsługujących HTTP/2. Mechanizm łączy nadużycie kompresji nagłówków HPACK z manipulacją kontrolą przepływu, co umożliwia utrzymywanie rosnącego zużycia pamięci przy niewielkim ruchu wejściowym. Szczególnie zagrożone są organizacje posiadające rozbudowaną infrastrukturę internetową, w tym operatorzy telekomunikacyjni, firmy technologiczne oraz placówki ochrony zdrowia.
- atak nie wymaga dużej przepustowości po stronie napastnika,
- celem jest pamięć operacyjna i stabilność procesów serwerowych,
- ryzyko dotyczy szeroko stosowanej infrastruktury webowej,
- dostępne są poprawki i działania ograniczające skutki ataku.
Kontekst / historia
HTTP/2 powstał jako nowocześniejsza i wydajniejsza alternatywa dla HTTP/1.1. Wprowadził multipleksowanie strumieni, kompresję nagłówków HPACK oraz mechanizmy kontroli przepływu, które miały ograniczać narzut transmisji i poprawiać wydajność komunikacji w środowiskach o dużej skali.
W czerwcu 2026 roku badacze opisali jednak scenariusz, w którym dwa zgodne ze specyfikacją elementy protokołu mogą zostać połączone w skuteczny wektor DoS. Problem ma znaczenie praktyczne, ponieważ dotyczy komponentów infrastrukturalnych powszechnie wykorzystywanych na styku internetu i usług biznesowych. Mowa o warstwie, która często działa od lat bez głębszego przeglądu architektury bezpieczeństwa, mimo że odpowiada za krytyczne funkcje publikacji aplikacji i API.
Dodatkowy ciężar ryzyka wynika z dużej popularności HTTP/2 w organizacjach obsługujących rozproszony ruch i wysokie obciążenia. W takich środowiskach nawet krótkotrwała niedostępność może prowadzić do zakłóceń operacyjnych, problemów z ciągłością działania i naruszeń poziomów usług.
Analiza techniczna
Istota HTTP/2 Bomb polega na uzyskaniu silnej amplifikacji zużycia pamięci po stronie serwera. Atakujący wysyła niewielkie żądania, które wymuszają budowę znacznie większych struktur związanych z przetwarzaniem nagłówków. Kluczową rolę odgrywa tutaj HPACK, czyli mechanizm kompresji nagłówków w HTTP/2, wykorzystujący tablice dynamiczne i indeksowanie zamiast ciągłego przesyłania pełnych danych tekstowych.
W scenariuszu nadużycia niewielki ruch wejściowy może powodować kosztowne operacje po stronie odbiorcy. Następnie kontrola przepływu HTTP/2 jest wykorzystywana do ograniczenia możliwości szybkiego odesłania odpowiedzi i zwolnienia zaalokowanych zasobów. W praktyce prowadzi to do sytuacji, w której pamięć pozostaje zajęta przez dłuższy czas, a kolejne żądania zwiększają presję na proces i RAM.
To odróżnia HTTP/2 Bomb od wielu tradycyjnych ataków DDoS nastawionych głównie na przepustowość łącza. Tutaj nie trzeba generować masowego ruchu, by osiągnąć efekt niedostępności. Celem staje się destabilizacja procesu odpowiedzialnego za obsługę HTTP/2 lub doprowadzenie do wyczerpania pamięci, co może skutkować błędami, restartami usług albo całkowitym przerwaniem obsługi klientów.
Ważne jest również to, że problem nie wynika z błędu logiki biznesowej aplikacji ani obejścia uwierzytelniania. Podatność znajduje się niżej, w warstwie implementacyjnej i protokolarnej. Oznacza to, że nawet poprawnie napisane aplikacje webowe mogą być zagrożone, jeśli korzystają z niezałatanych komponentów frontowych, reverse proxy lub bram API.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją HTTP/2 Bomb jest utrata dostępności usług internetowych. W sektorach takich jak telekomunikacja czy IT może to przełożyć się na niedostępność portali klientowskich, interfejsów API, paneli administracyjnych, systemów zaplecza i usług o dużej skali. W ochronie zdrowia wpływ jest szczególnie wrażliwy, jeśli zakłócenia dotkną systemów rejestracji, portali pacjenta lub usług wspierających komunikację medyczną.
Ryzyko zwiększają trzy kluczowe czynniki: popularność podatnych komponentów, niski koszt przeprowadzenia ataku po stronie przeciwnika oraz brak centralnego zarządzania konfiguracją HTTP/2 w wielu organizacjach. W praktyce protokół ten bywa traktowany jako przezroczysta funkcja platformy, a nie jako krytyczna powierzchnia ataku wymagająca aktywnego nadzoru.
- chwilowa lub długotrwała niedostępność usług,
- wzrost wykorzystania pamięci i niestabilność procesów serwerowych,
- przeciążenie warstw proxy i load balancerów,
- problemy z ciągłością działania i naruszenie SLA,
- wyższe koszty operacyjne związane z reagowaniem i analizą incydentu.
Dla zespołów bezpieczeństwa istotne jest również to, że klasyczne zabezpieczenia wolumetryczne lub proste limity zapytań mogą nie wystarczyć. Bez uwzględnienia specyfiki HTTP/2 oraz zachowania pamięci podczas przetwarzania nagłówków i blokowania odpowiedzi część środowisk może pozostać podatna mimo wdrożonych mechanizmów ochronnych.
Rekomendacje
Organizacje powinny w pierwszej kolejności zinwentaryzować wszystkie komponenty obsługujące HTTP/2 zarówno na brzegu infrastruktury, jak i wewnątrz środowiska. Obejmuje to główne serwery WWW, reverse proxy, gatewaye API, elementy service mesh, urządzenia bezpieczeństwa oraz platformy CDN.
- niezwłocznie wdrożyć poprawki dostawców dla podatnych implementacji,
- zweryfikować, gdzie HTTP/2 jest aktywne i czy jest rzeczywiście potrzebne,
- rozważyć czasowe ograniczenie lub wyłączenie HTTP/2 dla usług o najwyższym ryzyku,
- dostroić limity dotyczące nagłówków, liczby strumieni i zachowania połączeń,
- monitorować nietypowy wzrost zużycia pamięci przez procesy obsługujące HTTP/2,
- wdrożyć detekcję anomalii dla długotrwałych połączeń i nietypowych wzorców ramek,
- przetestować odporność usług w kontrolowanym środowisku przedprodukcyjnym,
- skoordynować działania między zespołami SOC, DevOps, SRE i administratorami sieci.
W środowiskach krytycznych warto przygotować plan awaryjny obejmujący szybkie przełączenie ruchu, zmianę profilu terminacji TLS/HTTP, eskalację do dostawców oraz gotowe playbooki reagowania na incydenty DoS warstwy aplikacyjnej. Dobrą praktyką jest również przegląd telemetrii pod kątem połączeń HTTP/2 utrzymujących niski transfer przy jednoczesnym rosnącym zużyciu pamięci.
Podsumowanie
HTTP/2 Bomb pokazuje, że funkcje projektowane z myślą o wydajności mogą stać się skutecznym wektorem ataku, jeśli zostaną połączone w nieoczekiwany sposób. Zagrożenie jest istotne, ponieważ dotyczy szeroko stosowanej infrastruktury webowej i pozwala osiągnąć znaczący efekt odmowy usługi przy niskim koszcie po stronie napastnika.
Dla organizacji z sektorów telekomunikacyjnego, IT i ochrony zdrowia priorytetem powinno być szybkie wdrożenie poprawek, przegląd ekspozycji usług HTTP/2 oraz wzmocnienie monitoringu dostępności i zużycia zasobów. To kolejny sygnał, że bezpieczeństwo warstwy protokołów pozostaje równie ważne jak ochrona samej aplikacji.
Źródła
- Dark Reading — HTTP/2 Bomb Attacks Put Telcos, Healthcare Orgs at Risk — https://www.darkreading.com/vulnerabilities-threats/http-2-bomb-attacks-telcos-healthcare
- Imperva Blog — Imperva Protects Against CVE-2026-49975 HTTP/2 Bomb — https://www.imperva.com/blog/imperva-customers-protected-against-cve-2026-49975-http-2-bomb-dos/
- RFC 9113 — HTTP/2 — https://www.ietf.org/rfc/rfc9113.pdf
- RFC 7541 — HPACK: Header Compression for HTTP/2 — https://www.ietf.org/ietf-ftp/rfc/rfc7541.txt.pdf
- Radware Cybersecurity Alert — HTTP/2 Bomb June 2026 — https://www.radware.com/getattachment/38a70d60-bd2d-45ba-a44d-b7f12ca5d4d3/Threat-Alert-HTTP2-Bomb-June2026.pdf.aspx