HTTP/2 Bomb: kaip vienas nešiojamas kompiuteris per sekundes nugalabija nginx, Apache ir IIS

2026 m. birželio 3 d. kompanija Calif paskelbė HTTP/2 Bomb — nuotolinę DoS ataką prieš nginx, Apache httpd, Microsoft IIS, Envoy ir Cloudflare Pingora. Jokio botneto nereikia: paprastas namų kompiuteris su 100 Mbps kanalu pargriaudina pažeidžiamą serverį per kelias sekundes. Prieš Apache httpd ir Envoy vienas klientas sunaudoja ir išlaiko 32 GB serverio atminties per maždaug 20 sekundžių.

Ataką rado ne žmogus — ją rado OpenAI Codex. Tyrėjas Quang Luong davė modeliui užduotį išanalizuoti populiarių HTTP/2 serverių kodų bazes ieškant pavojingų žinomų technikų derinių. Codex sujungė du metodus, kiekvieną iš kurių bendruomenė žino jau daugiau nei dešimt metų, ir gavo ataką, kurios nenumatė nė vienas paveiktų serverių kūrėjų.

nginx pažeidžiamybė uždaryta versijoje 1.29.8 (mainline) ir 1.30.0+ (stable). Jei jau atsinaujinote iki 1.30.2 po ankstesnių CVE — nginx-rift ir CVE-2026-9256 — jūsų serveris apsaugotas. Apache httpd turi pataisymą mod_http2 v2.0.41, priskirtas CVE-2026-49975. IIS, Envoy ir Cloudflare Pingora publikavimo metu pataisymų neturi.

KAS YRA HTTP/2 BOMB

Įsivaizduokite bibliotekininkę su puikia atmintimi: įvardijate knygą vieną kartą, ji padeda ją į lentyną, o toliau galite prašyti jos vienu žodžiu — ji visada atneš pilną kopiją. HTTP/2 HPACK veikia taip pat: siuntėjas vieną kartą įrašo antraštę į dinaminę lentelę, tada ją nurodo vienu baitu. Gavėjas kiekvieno nurodymo metu materializuoja pilną antraštės struktūrą atmintyje. Puiku taupant srautą normalaus darbo metu. Problema — kai antraštė maža, o nuorodų tūkstančiai.

HTTP/2 (RFC 9113) prideda srauto valdymą: gavėjas deklaruoja lango dydį, ir siuntėjas negali perduoti duomenų viršijant tą langą, kol negauna WINDOW_UPDATE. Esminis dalykas — klientas valdo serverio atsakymų langą. Tai reiškia, kad klientas gali išlaikyti atvirą srautą kiek nori ilgai, periodiškai siųsdamas minimalius WINDOW_UPDATE kadrus, kad išvengtų uždarymo dėl skirtojo laiko. HTTP/2 Bomb jungia abu mechanizmus: greitai pripildyti atmintį per HPACK ir niekada jos neišlaisvinti per Window Stall.

KAIP VEIKIA KLAIDA

Pirmoji dalis — HPACK Indexed Reference Bomb. Užpuolikas įrašo vieną antraštę į dinaminę lentelę, tada vieno užklausos metu siunčia tūkstančius vieno baito indeksinių nuorodų į ją. Kiekviena nuoroda užpuolikui kainuoja vieną baitą tinkle, tačiau verčia serverį paskirstyti pilną antraštės struktūrą. Stiprinimo koeficientas priklauso nuo realizacijos:

| Serveris                            | Stiprinimas | Demo rezultatas  |
|-------------------------------------|-------------|------------------|
| Envoy 1.37.2                        | ~5 700:1    | ~32 GB per ~10s  |
| Apache httpd 2.4.67                 | ~4 000:1    | ~32 GB per ~18s  |
| nginx 1.29.7                        | ~70:1       | ~32 GB per ~45s  |
| Microsoft IIS (Windows Server 2025) | ~68:1       | ~64 GB per ~45s  |

Verta suprasti, kodėl įprastinė apsauga nesuveikė. Ankstesnės HPACK bombos (CVE-2016-6581) į lentelę dėjo didelę reikšmę ir į ją kartotinai nurodydavo. Serveriai išmoko riboti bendrą dekoduotų antraščių dydį. HTTP/2 Bomb eina kita kryptimi: antraštės reikšmė beveik tuščia, o stiprinimas kyla iš alokatoriaus priskyriamų papildomų išlaidų kiekvienam įrašui. Dekoduoto dydžio limitas niekada nesuveikia, nes beveik nėra ką dekoduoti.

Antroji dalis — HTTP/2 Window Stall. Užpuolikas deklaruoja nulinį srauto valdymo langą serverio atsakymui. Serveris negali baigti perduoti atsakymo, neuždaro srauto, neišlaisvina atminties. Kad ryšys neužsidarytų dėl skirtojo laiko, užpuolikas periodiškai siunčia minimalius WINDOW_UPDATE kadrus — serveris mato aktyvumą ir toliau laiko srautą gyvą. Visa paskirta atmintis lieka užrakinta tol, kol užpuolikas palaiko ryšį.

Abu metodai kartu sukuria situaciją, kai atmintis paskirstoma greitai ir niekada neišlaisvinama. Kaip pažymi Calif, OOM procesą žudyti netikslinga — nužudytas darbininkas tiesiog paleis iš naujo švarius. Veiksmingiau laikyti atminties spaudimą šiek tiek žemiau OOM-killer ribos, nustumti mašiną į swap ir laukti, kol kiekviena serverio užklausa pradės lėtėti.

KAIP TAI IŠNAUDOJAMA

Apache ir Envoy turi antraščių laukų skaičiaus limitą — atrodytų, apsauga. Tačiau RFC 9113 §8.2.3 specifikacija aiškiai leidžia skaidyti antraštę Cookie į atskirus laukus po vieną trupinį kiekvienam laukui. Nei Apache, nei Envoy neskaičiavo tų trupinių prieš savo limitą. Apėjimas elegantiškas: eini per tą įėjimą, kurį pats standartas paliko atvirą.

Envoy kiekvienas cookie trupinys pridedamas į buferį — 4 KB reikšmė, nurodyta 32 000 kartų, duoda ~3 600:1 loginį stiprinimą, o išmatuotas RSS santykis siekia ~5 700:1 viename sraute įskaitant alokatorius papildomas išlaidas. Apache httpd kiekvieno naujo trupinio metu iš naujo sujungia visą cookie eilutę, palikdamas kiekvieną senesnę kopiją gyvą iki srauto valymo — todėl net tuščia cookie reikšmė duoda ~4 000:1.

PoC skriptai, Docker laboratorijos ir išsamūs writeup’ai kiekvienam serveriui paskelbti GitHub’e (califio/publications/tree/main/MADBugs/http2-bomb). Kelias nuo commit iki exploit yra trumpas — Calif tiesiogiai įspėja, kad bet koks šiuolaikinis kalbos modelis gali paversti viešus pataisymų diff’us veikiančiu exploit.

REALUS ATAKOS SCENARIJUS

Užpuolikas atidaro HTTP/2 ryšį su serveriu — jokio autentifikavimo, jokių išankstinių žinių apie konfigūraciją nereikia. Užpildo HPACK dinaminę lentelę viena antrašte, tada vienos užklausos metu siunčia tūkstančius vieno baito nuorodų į ją — serveris skirsto struktūras, užpuolikas eikvoja baitus. Tuo pat metu deklaruoja nulinį langą serverio atsakymui, neleisdamas nė vienam srautui užsidaryti.

Su nginx 70:1 stiprinimo koeficientu ir 100 Mbps kanalu užpuolikas gali generuoti ~7 Gbps atminties apkrovos ekvivalentą — be jokio botneto. Apache ir Envoy su 4 000–5 700:1 stiprinimu pasiekia 32 GB per 10–20 sekundžių tipiniame VPS. Serveris nekrenta iš karto — jis degraduoja: naujos užklausos pradeda apdorojamos vis lėčiau, kol visiškai nustoja apdorojamos.

Shodan duomenimis, daugiau nei 880 000 svetainių palaiko HTTP/2 ir veikia ant vieno iš paveiktų serverių. Daugelis yra už CDN — tai ženkliai mažina riziką — tačiau tiesioginės instaliacijos be tarpininkavimo yra visiškai atviros.

LAIKO JUOSTA

2026 m. balandžio mėnesį Calif atskleidė pažeidžiamybę nginx komandai. Kūrėjai reagavo kitą dieną — importavo direktyvą max_headers iš freenginx ir išleido nginx 1.29.8. Commit: 365694160a85229a7cb006738de9260d49ff5fa2. Ta pati direktyva max_headers su numatytuoju 1000 limitu pateko ir į stable šaką: nginx 1.30.0 išėjo 2026 m. balandį su ta pačia apsauga.

2026 m. gegužės 27 d. Calif atskleidė pažeidžiamybę Apache komandai. Stefan Eissing ją pataisė tą pačią dieną, priversdamas cookie antraštes skaičiuotis prieš LimitRequestFields limitą. Commit: 47d3100b252dc6668a9e46ae885242be9eeca9cd. Pažeidžiamybei priskirtas CVE-2026-49975.

2026 m. birželio 3 d. Calif paskelbė pilną writeup, PoC skriptus ir Docker laboratorijas. Tuo pat metu jie atskleidė, kad būtent viešieji pataisymų diff’ai padėjo jiems aptikti pažeidžiamybę IIS, Envoy ir Pingora — AI modelis perskaitė commit’us ir savarankiškai rado analogiškus šablonus kituose serveriuose. Microsoft, Envoy ir Cloudflare informuoti; pataisymų publikavimo metu nėra.

KAIP TAI IŠGYVENO DEŠIMT METŲ

HPACK Bomb kaip koncepcija egzistuoja nuo 2016 metų — CVE-2016-6581, Cory Benfield. Slowloris tipo išsekimas per HTTP/2 — taip pat 2016 metai: CVE-2016-8740 ir CVE-2016-1546. 2025 metais Gal Bar Nahum pasiekė ~4 000:1 stiprinimą prieš Apache httpd per CVE-2025-53020. Visos šios technikos viešos, dokumentuotos, buvo uždaromos atskirais pataisymais.

Problema ta, kad kiekvieną kartą buvo uždaromas konkretus vektorius, o ne pagrindinė priežastis. Serveriai išmoko riboti bendrą dekoduotų antraščių dydį — ir kaip tik todėl nauja ataka veikia per alokatorius lygio papildomas išlaidas kiekvienam įrašui, o ne per reikšmių dydį. RFC 7541 turi visą §7.3 „Memory Consumption” skyrių, įspėjantį, kad užpuolikas gali bandyti išsemti atmintį per HPACK. Skyrius paaiškina, kad HPACK riboja lentelę per SETTINGS_HEADER_TABLE_SIZE ir laiko problemą išspręsta. Tačiau kai penkios nepriklausomos realizacijos perskaitė tą skyrių ir vis tiek pasirodė pažeidžiamos — defektas specifikacijoje, o ne realizacijose.

Calif writeup autorius prideda asmeninį kontekstą: 2012 metais jis dalyvavo atrandant CRIME ataką prieš HTTP antraščių glaudinimą, o vėliau buvo pakviestas recenzuoti pataisymą — kuris tapo HPACK. Perskaitęs savo to laikotarpio užrašus, jis atrado: nė karto nesvarstė šios atakos. Buvo per daug susikoncentravęs į CRIME kovą ir praleido bombą.

KODĖL TAI SVARBU

nginx administratoriams tai trečia kritinė pažeidžiamybė per kelis mėnesius — po nginx-rift ir CVE-2026-9256 (nginx-poolslip, CVSS 9.2). Jei atsinaujinote iki 1.30.2 po tų CVE per oficialią nginx.org saugyklą — direktyva max_headers jau yra jūsų surinkime ir veikia su numatytuoju 1000 limitu. Jei dar esate ant Ubuntu paketo 1.24.0 — esate pažeidžiami visų trijų iš karto.

Ši ataka principingai skiriasi nuo tradicinio DDoS. Tradicinis DDoS reikalauja pralaidumo: norint užkimšti 1 Gbps serverio kanalą, reikia generuoti 1 Gbps srauto. HTTP/2 Bomb su 70:1 koeficientu nginx atveju leidžia sukurti 7 Gbps atminties apkrovos ekvivalentą iš 100 Mbps namų ryšio. Apache su 4 000:1 — 400 Gbps ekvivalentą iš to paties ryšio. CDN kaip Cloudflare savo infrastruktūra ženkliai mažina riziką, tačiau tiesioginės instaliacijos be tarpininkavimo yra visiškai atviros.

Atskiro dėmesio vertas atakos atradimo būdas. Abu primitivai viešieji daugiau nei dešimt metų. Codex perskaitė serverių kodų bazes, atpažino, kad dvi technikos derinasi, ir sukonstruavo kombinuotą ataką. Tai akivaizdu matant rezultatą — ir vis dėlto, kiek galima spręsti, nė vienas žmogus anksčiau nesurinko šio derinio prieš šiuos serverius.

ATNAUJINIMAS

Pirmiausia — suprasti savo situaciją. Patikrinti nginx versiją ir apsaugos buvimą:

nginx -v
nginx -T | grep max_headers

Jei versija 1.30.0+ (stable) arba 1.29.8+ (mainline) — apsauga jau veikia. Jei grep nieko negrąžino — direktyva nėra nustatyta aiškiai, tačiau numatytasis 1000 limitas veikia automatiškai nuo šių versijų. Jei versija žemesnė — skaitykite toliau.

1 scenarijus: nginx.org saugykla jau prijungta. Patikrinkite kas bus įdiegta ir atnaujinkite:

apt-cache policy nginx

Eilutėje Candidate: turi būti 1.30.x iš origin nginx.org. Jei taip — atnaujinkite:

apt update && apt install nginx

2 scenarijus: dar naudojate Ubuntu paketą 1.24.0. Prijungiame nginx.org saugyklą. GPG raktas — per pipe su dearmor, kaip nurodo oficiali nginx.org dokumentacija:

curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor \
| sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null

Patikrinkite fingerprint — nepraleiskite šio žingsnio:

gpg --dry-run --quiet --no-keyring \
  --import --import-options import-show \
  /usr/share/keyrings/nginx-archive-keyring.gpg

Tikėtini fingerprint’ai (patikrinkite aktualius nginx.org/en/pgp_keys.html):

8540A6F18833A80E9C1653A42FD21310B49F6B46
573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62
9E9BE90EACBCDE69FE9B204CBCDCD8A38D88A2B3

Jei nesutampa — nedelsdami ištrinkite failą. Jei sutampa — pridėkite saugyklą (stable 1.30.x) ir pinning:

echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
https://nginx.org/packages/ubuntu $(lsb_release -cs) nginx" \
| sudo tee /etc/apt/sources.list.d/nginx.list

cat > /etc/apt/preferences.d/nginx << 'EOF'
Package: nginx*
Pin: origin nginx.org
Pin-Priority: 900
EOF

apt update && apt install nginx

Kai apt paklaus apie konfigūracijos failą — pasirinkite N, palikite savo versiją. Po atnaujinimo patikrinkite:

nginx -v && nginx -t && systemctl reload nginx

Šis atnaujinimas uždaro tris pažeidžiamybes iš karto: nginx-rift, CVE-2026-9256 ir HTTP/2 Bomb.

3 scenarijus: dnf sistemos (RHEL, Rocky Linux, AlmaLinux). Procedūra analogiška Ubuntu — prijunkite nginx.org saugyklą per nginx.org/en/linux_packages.html, naudodami dnf vietoje apt.

Apache httpd. Situacija sudėtingesnė — pataisymas standalone mod_http2 v2.0.41 nepateko į pagrindinę httpd 2.4.x versiją, oficialaus apt paketo nėra. Saugiausias kelias dabar — išjungti HTTP/2:

# httpd.conf arba virtualaus hosto konfigūracijoje
Protocols http/1.1

apachectl configtest
systemctl reload apache2
curl -I --http2 https://example.com 2>&1 | grep -i "HTTP/"

Jei atsakyme HTTP/1.1 — HTTP/2 išjungtas. Jei norite įdiegti mod_http2 v2.0.41 išlaikant HTTP/2 — surinkimo instrukcija README github.com/icing/mod_h2. Kai pataisymas pateks į pagrindinę httpd versiją — pereikite prie standartinio paketo.

Visiems serveriams — papildoma priemonė. Apriboti darbininko atmintį. Darbininkas, OOM-killer nužudytas ir iš naujo paleistas švarius, yra geriau nei mašina, patenkanti į swap užpuoliko kontrolėje:

# /etc/systemd/system/nginx.service.d/override.conf
[Service]
LimitAS=2G

systemctl daemon-reload && systemctl restart nginx

IIS, Envoy, Cloudflare Pingora — pataisymų nėra. Išjunkite HTTP/2 arba perduokite per nginx 1.30.x.

IŠVADOS

HTTP/2 Bomb — tai ne nauja technika, o naujoviškas senų technikų derinys, kurio niekas nesurinkė dešimt metų. Vienas namų kompiuteris, 100 Mbps, kelios sekundės — ir jūsų serveris degraduoja po apkrova, ekvivalenčia šimtams gigabitų.

Jei esate ant nginx 1.30.2 — jau apsaugoti, nieko daryti nereikia. Jei ne — atnaujinimas iki 1.30.2 per nginx.org saugyklą uždaro tris aktualias pažeidžiamybes iš karto: nginx-rift, CVE-2026-9256 ir HTTP/2 Bomb. Viena komanda, trys problemos.