Jeśli masz serwer WWW z domyślną konfiguracją HTTP/2 — sprawdź, którego używasz, bo łatki są dostępne nierówno. nginx: zaktualizuj do 1.29.8+ (dodaje dyrektywę max_headers z domyślnym limitem 1000). Apache httpd: mod_http2 2.0.41 / 2.4.67. Dla IIS, Envoy i Pingora w momencie ujawnienia nie było łatek — Envoy wydał poprawkę 3 czerwca. Jeśli nie możesz zaktualizować: wyłącz HTTP/2 (http2 off;), postaw przed serwerem proxy lub firewall wymuszający twardy limit liczby nagłówków, i ogranicz pamięć procesów roboczych.
Ponad 880 000 publicznych portali ma podatną konfigurację. PoC jest już publiczny.
CVE-2026-49975, nazwany HTTP/2 Bomb, to zdalny atak odmowy usługi działający na większość głównych serwerów WWW w ich domyślnej konfiguracji HTTP/2 — nginx, Apache httpd, Microsoft IIS, Envoy, Cloudflare Pingora. Crashuje serwer w mniej niż minutę. Nie wymaga uwierzytelnienia, nie wymaga interakcji użytkownika, nie wymaga egzotycznego narzędzia. Wymaga klienta, połączenia i wiedzy, jak dwie dobrze znane mechaniki protokołu zachowują się, gdy połączyć je w sposób, na który implementacje serwerów nie były przygotowane.
Ale najważniejsze w tej historii nie jest to, jak atak działa. Najważniejsze jest to, jak został znaleziony — i jak ta sama metoda znalezienia stała się metodą rozprzestrzenienia.
Pętla, którą opisujemy od miesięcy, zamknięta w jednym incydencie
Firma Calif.io opisała genezę wprost: HTTP/2 Bomb znalazł Codex — agentowy model OpenAI do kodowania.
I tu jest zdanie, które jest sednem całej sprawy. Zgłosiliśmy do Apache 27 maja, Stefan Eissing naprawił to tego samego dnia. Commity z łatkami są publiczne i ujawniają wektory bezpośrednio; dowolny zdolny model AI może zamienić te diffy w działający exploit — i dokładnie tak znaleźliśmy, że Microsoft IIS, Envoy i Pingora też są podatne. The Hacker News
Przeczytaj to jeszcze raz, bo to jest cała trajektoria maja w jednym akapicie. AI znajduje podatność w Apache. Apache publikuje łatkę. Z tej publicznej łatki AI odczytuje wektor ataku i używa go do sprawdzenia innych serwerów — i znajduje, że IIS, Envoy i Pingora mają ten sam problem. Łatka, która miała zamknąć podatność, stała się mapą do znalezienia jej kopii gdzie indziej.
Pisaliśmy o tym przy Marimo — że samego opisu podatności wystarcza AI do zbudowania exploita. Pisaliśmy przy GTIG, że AI generalizuje z jednego przypadku na sąsiednie. HTTP/2 Bomb jest pierwszym incydentem, w którym widać obie strony tej samej pętli naraz: AI po stronie obrońcy znajduje błąd, a publiczna łatka natychmiast staje się materiałem dla AI po stronie znajdowania kolejnych celów. Calif.io ujmuje konsekwencję wprost: biorąc pod uwagę, jak krótka jest teraz ścieżka od commita do exploita, publikujemy ten opis, by dać użytkownikom poniższe mitygacje. The Hacker News
To jest dokładnie okno, które Radar #2 nazwał jako zamykające się — czas między ujawnieniem a eksploatacją liczony już nie w dniach, ale w długości, jakiej AI potrzebuje na przeczytanie diffa.
Jak działa bomba
HTTP/2 Bomb nie jest nową techniką — jest kompozycją znanych. To jest istotne, bo pokazuje, czego AI faktycznie dokonało: nie wymyśliło nowej klasy ataku, ale znalazło nowy sposób połączenia istniejących mechanik, których implementacje serwerów nie spodziewały się razem.
Atak ma dwie części. Pierwsza używa HPACK Bomb (CVE-2016-6581) — ataku na warstwę kompresji, polegającego na małych wiadomościach, które po dotarciu do serwera docelowego zamieniają się w gigabajty danych. W zeszłym roku atak zademonstrowano przeciwko Apache HTTPD ze współczynnikiem amplifikacji 4000x. Mała wiadomość wchodzi, gigabajty pamięci są alokowane po stronie serwera. The Hacker News
Druga część celuje w CVE-2016-8740 i CVE-2016-1546 (Slow Read) — dwie podatności Apache HTTPD prowadzące do warunków DoS przez ramki Continuation w żądaniu HTTP/2 i przez zmodyfikowane okna kontroli przepływu. Te problemy typu HTTP/2 Slowloris są nadużywane do wyczerpania pamięci przez reklamowanie zerobajtowego okna kontroli przepływu, tak że serwer nie wysyła odpowiedzi, a następnie zresetowanie limitu czasu wysyłania, by uniemożliwić serwerowi zwolnienie alokacji pamięci. The Hacker News
Połączenie jest perfidne. Pierwsza część zmusza serwer do zaalokowania ogromnej ilości pamięci. Druga część uniemożliwia mu jej zwolnienie. Ta taktyka popycha środowisko hosta w intensywne cykle swap zamiast wymuszać czysty crash procesu. W rezultacie żądania legalnych użytkowników zwalniają do całkowitego zatrzymania. Serwer nie pada efektownie — dławi się powoli, co jest trudniejsze do zdiagnozowania niż zwykły crash. Cyber Press
Konkretny mechanizm w Apache, który Stefan Eissing naprawił tego samego dnia: sprawienie, by nagłówki cookie liczyły się do LimitRequestFields. Fragmenty cookie, które wcześniej nie były liczone do limitu pól żądania, pozwalały obejść zabezpieczenie. W nginx odpowiedź to nowa dyrektywa max_headers z domyślnym pułapem 1000 nagłówków. The Hacker News
Nierówna łatka, nierówne ryzyko
Jest tu szczegół, który jest praktycznie ważniejszy niż sam mechanizm: nie wszyscy producenci załatali jednocześnie, a niektórzy w momencie publikacji nie załatali wcale.
Problem naprawiono w nginx 1.29.8, który dodał dyrektywę max_headers, oraz w Apache httpd mod_http2 2.0.41, gdzie przypisano identyfikator CVE-2026-49975. W momencie pisania nie ma łatki dla IIS, Envoy ani Pingora. Envoy wydał poprawkę 3 czerwca, którą Calif.io wciąż walidował pod kątem ewentualnych luk. University of Michigan Safecomputing
To tworzy nierówny krajobraz ryzyka. nginx i Apache — załatane, jeśli zaktualizujesz. IIS, Pingora — w momencie ujawnienia bez łatki, z PoC już publicznym. Dla tych serwerów jedyną obroną była konfiguracja: wyłączenie HTTP/2 tam, gdzie to wykonalne, i postawienie z przodu proxy lub firewalla wymuszającego twarde limity liczby nagłówków.
Część wdrożeń jest naturalnie chroniona. Systemy działające za CDN-ami lub reverse proxy nie wystawiają podatnego endpointu HTTP/2 i są trudniejsze do zaatakowania. Niektóre wdrożenia mogą już mieć własne limity liczby nagłówków, WAF-y, reverse proxy lub wyłączony HTTP/2. University of Michigan Safecomputing
Skala ekspozycji jest jednak duża: parametry wyszukiwania Shodan wskazują, że ponad 880 000 aktywnych publicznych portali WWW wystawia obecnie tę podatną konfigurację protokołu. Cyber Press
Drugi poważny problem HTTP/2 w miesiąc
To nie jest pierwsza poważna podatność HTTP/2, którą widzimy w tym okresie. Miesiąc temu pojawił się CVE-2026-23918 — double-free w mod_http2 Apache httpd 2.4.66, opisany jako „double free i możliwe RCE", CVSS 8.8, prowadzący do DoS i pod pewnymi warunkami do zdalnego wykonania kodu. Co ciekawe, tamtą podatność zgłosili polscy badacze — Bartłomiej Dmitruk ze Striga.ai i Stanisław Strzałkowski z ISEC.pl. Security Affairs
Dwie poważne podatności HTTP/2 w jednym miesiącu, w tym samym module Apache, to nie przypadek. To jest wzorzec, który opisywaliśmy przy serii kernela Linuksa — gdy jeden obszar protokołu trafia pod lupę (badaczy albo AI), kolejne błędy tej samej klasy zaczynają się sypać, bo wszyscy patrzą w to samo miejsce. HTTP/2 to złożony protokół z wieloma mechanikami, które wchodzą w interakcje — a złożoność, która wchodzi w interakcje, jest dokładnie tym, co AI radzi sobie analizować lepiej niż człowiek.
Co zrobić
nginx: zaktualizuj do 1.29.8 lub nowszej. Domyślny limit max_headers 1000 wystarcza.
Apache httpd: zaktualizuj mod_http2 do 2.0.41 albo Apache do 2.4.67 (co zamyka też miesięczny CVE-2026-23918).
Envoy: zastosuj czerwcową poprawkę, ale monitoruj komunikaty — w momencie pisania jej kompletność była jeszcze walidowana.
IIS i Pingora: bez dostępnej łatki w momencie ujawnienia. Wyłącz HTTP/2, jeśli to wykonalne. Postaw przed serwerem proxy lub firewall z twardym limitem liczby nagłówków. Zastosuj limity pamięci na procesach roboczych, żeby pojedynczy atak nie wyczerpał zasobów całego systemu.
Jeśli jesteś za CDN-em lub reverse proxy z własnymi limitami nagłówków — prawdopodobnie jesteś chroniony, ale zweryfikuj, że podatny endpoint HTTP/2 nie jest wystawiony bezpośrednio.
Źródła
Calif.io — pierwotny opis odkrycia przez Codex i analiza ścieżki commit-to-exploit: https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb
BleepingComputer — szczegóły mitygacji i status łatek poszczególnych serwerów: https://www.bleepingcomputer.com/news/security/new-http-2-bomb-dos-attack-crashes-web-servers-in-under-a-minute/
SecurityWeek — analiza dwóch części exploita (HPACK Bomb + Slow Read): https://www.securityweek.com/http-2-bomb-exploit-knocks-web-servers-offline-in-seconds/
CybersecurityNews — oś czasu disclosure i historia powiązanych CVE: https://cybersecuritynews.com/http-2-bomb-remote-dos-exploit/
securityonline.info — dane Shodan o skali ekspozycji i publikacja PoC: https://securityonline.info/http2-bomb-exploit-poc-disclosed/
Tenable — lista dotkniętych serwerów i status CVE-2026-49975: https://www.tenable.com/cve/CVE-2026-49975
Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł