Tehnička anatomija: Kako funkcioniše „HTTP/2 Bomb“?

Za razliku od klasičnih DDoS napada koji se oslanjaju na sirovu snagu (tzv. volumetric attacks gde se server preplavljuje gigabajtima saobraćaja kroz botnete), HTTP/2 Bomb je hirurški precizan asimetrični napad. To znači da napadač troši minimalne resurse (bilo propusni opseg ili procesorsku snagu), dok žrtva (server) biva primorana da alocira ogromne količine memorije dok potpuno ne ostane bez resursa (Out of Memory – OOM krah).

Tehnika se bazira na ulančavanju (chaining) dva odvojena mehanizma koji su u svetu bezbednosti poznati već dugi niz godina:

Kompresiona bomba (HPACK Bomb) 

Zadržavanje toka u stilu Slowloris napada (Slow Read) 

1. Prva faza: HPACK kompresiona bomba

U HTTP/2 protokolu, zaglavlja (headers) se kompresuju pomoću algoritma zvanog HPACK. HPACK koristi takozvanu dinamičku tabelu u kojoj se jednom poslata zaglavlja indeksiraju, kako se ne bi ponovo slala kroz mrežu, čime se štedi protok.

Prethodne verzije kompresionih bombi radile su tako što bi napadač smestio ogromnu vrednost u tabelu i onda je konstantno pozivao. Moderni veb serveri su naučili da se brane od ovoga uvođenjem limita na ukupnu veličinu dekodiranog zaglavlja (decoded header size limit).

Međutim, HTTP/2 Bomb koristi potpuno obrnutu taktiku:

Zaglavlje koje napadač šalje je skoro potpuno prazno.

Amplifikacija (umnožavanje) ne dolazi iz veličine samih podataka, već iz interne administrativne strukture (bookkeeping) koju server mora da kreira za svaki pojedinačni unos u tabelu.

Na ovaj način, jedan jedini bajt poslat kroz mrežu tera server da alocira čitavu memorijsku strukturu za zaglavlje, i to se ponavlja na hiljade puta u okviru samo jednog zahteva.

S obzirom na to da je stvarna veličina dekodiranih podataka minimalna, bezbednosni limiti za veličinu zaglavlja se nikada ne aktiviraju.

2. Druga faza: Slowloris zadržavanje memorije

Sama alokacija memorije ne bi bila dovoljna da sruši server ako bi on brzo obradio zahtev, poslao odgovor i odmah oslobodio tu memoriju. Tu na scenu stupa drugi deo slagalice – hibridni Slowloris hold.

Napadač koristi HTTP/2 mehanizam kontrole toka (flow control) i serveru signalizira da mu je prozor za prijem podataka nula bajtova (WINDOW_UPDATE postavljen na 0).

Ovo praktično znači da serveru govori: “Generisao sam zahtev, ti pripremi odgovor, ali nemoj još ništa da mi šalješ jer nemam mesta u memoriji”.

Da veb server ne bi prekinuo vezu zbog tajmauta (timeout), napadač periodično šalje minimalne pakete od samo 1 bajta.

Rezultat: Server je primoran da drži gigabajte alocirane memorije „zarobljene“ u sistemu, čekajući da pošalje odgovor koji nikada neće biti poslat. Za manje od minuta, memorija servera biva potpuno iscrpljena.

AI kao pronalazač: Kako je Codex nadmudrio ljudske programere?

Jedan od najfascinantnijih aspekata ranjivosti CVE-2026-49975 jeste način na koji je otkrivena. Prema izveštaju kalifornijske kompanije za sajber bezbednost Calif, obe tehnike korišćene u ovom napadu (HPACK bomba i Slowloris) javno su poznate već čitavu deceniju. Tokom deset godina, hiljade bezbednosnih stručnjaka, inženjera i revizora koda prošlo je kroz baze podataka najpopularnijih veb servera i niko nije uočio da se ove dve komponente mogu spojiti na ovaj način.

Istraživači su uposlili OpenAI Codex model koji je analizirao izvorne kodove serverskih platformi. AI je prepoznao arhitektonsku sličnost i logički zaključio da se ove dve odvojene funkcije savršeno uklapaju u destruktivan napad. Čim su ove dve metode spojene, kreiran je funkcionalan Proof-of-Concept (PoC) kod koji potvrđuje ranjivost.

Ovo otvara potpuno novu eru u sajber bezbednosti – eru u kojoj AI može da uoči skrivene logičke greške u softveru koje su ljudima promicale godinama, ali isto tako postavlja pitanje šta će se desiti kada zlonamerni akteri počnu masovno da koriste AI za generisanje do sada neviđenih eksploita.

Obim pretnje: Koje platforme su pogođene?

Ranjivost se ne nalazi u nekom opskurnom softveru, već direktno pogađa podrazumevane (default) HTTP/2 konfiguracije stubova modernog interneta. Prema Shodan pretragama koje su sproveli istraživači, preko 880.000 veb sajtova direktno je izloženo ovom napadu.

Pogođeni su sledeći serveri i proksiji:

NGINX: Jedan od najpopularnijih veb servera na svetu, osnova za milione visokoprometnih sajtova.

Apache HTTPD: Tradicionalni lider u serverskom svetu koji pokreće ogroman procenat enterpriz i open-source veb lokacija.

Microsoft IIS: Server integrisan u Windows Server operativne sisteme, standard u korporativnim okruženjima.

Envoy: Izuzetno popularan proksi i komunikacioni bus koji se masivno koristi u klaud-nejtiv (cloud-native) arhitekturama i mikroservisima.

Cloudflare Pingora: Moderni proksi koji je Cloudflare razvio u Rust-u kako bi zamenio NGINX u svojoj globalnoj mreži.

Tokom kontrolisanih laboratorijskih testiranja, istraživači iz kompanije Calif zabeležili su sledeće performanse napada pri brzini od samo 100 Mbps:

Napomena: Iako mnogi sajtovi koriste Content Delivery Network (CDN) mreže koje pružaju određeni nivo zaštite i komplikuju direktno izvršenje napada, sam broj sirovo izloženih servera na internetu predstavlja ogroman bezbednosni rizik. 

Trenutni status zakrpa (Jun 2026.)

Bezbednosna zajednica i razvojni timovi pogođenih projekata su reagovali različitim brzinama kako bi neutralisali ovaj napad:

NGINX je reagovao najbrže i rešio ovaj problem implementacijom nove bezbednosne direktive pod nazivom max_headers, koja eksplicitno ograničava broj administrativnih unosa, sprečavajući trik sa deljenjem kolačića.

Apache HTTP Server je izdao popravku kroz ažuriranje mod_http2 v2.0.41, gde se fragmentisani delovi kolačića striktno računaju u ukupne limite polja zahteva. Ranjivost je u okviru Apache ekosistema pokrivena pomenutom oznakom CVE-2026-49975.

Envoy je objavio zvaničnu zakrpu 3. juna 2026. godine, ubrzo nakon javnog obelodanjivanja pretnje.

Microsoft IIS i Cloudflare Pingora u trenutku pisanja ovog izveštaja i inicijalnog objavljivanja od strane istraživača još uvek nisu imali zvanične, javno dostupne zakrpe, iako su njihovi razvojni timovi uredno obavešteni o detaljima propusta kako bi hitno razvili rešenja.

Kako se zaštititi? Preporuke za sistem administratore

Ukoliko upravljate serverima ili infrastrukturom koja se oslanja na HTTP/2 protokol, neophodno je odmah preduzeti korake za ublažavanje rizika, naročito ako koristite platforme za koje zakrpe još uvek nisu izbačene.

1. Hitno ažuriranje softvera

Ovo je primarna i najvažnija mera. Ukoliko koristite NGINX, Apache ili Envoy, odmah povucite najnovije verzije iz zvaničnih riznica i primenite ažuriranja koja zatvaraju eksploit lanac CVE-2026-49975.

2. Privremeno isključivanje HTTP/2 protokola

Ako koristite Microsoft IIS ili sisteme za koje zakrpa još uvek nije dostupna, a serveri su vam kritični za poslovanje, razmislite o privremenom onesposobljavanju HTTP/2 podrške i vraćanju na stabilni HTTP/1.1. Iako će ovo doneti blagi pad performansi u brzini učitavanja elemenata, u potpunosti eliminiše HPACK i HTTP/2 kontrolu toka kao vektore napada.

3. Postavljanje tvrdih limita na zaglavlja (Header Caps)

Ukoliko ne možete da isključite HTTP/2, postavite proksi ispred vaših glavnih servera (npr. napredni Web Application Firewall – WAF) koji će vršiti striktnu inspekciju i primenjivati tvrde limite na maksimalan broj polja u zaglavlju po jednom zahtevu. Ako zahtev sadrži anomalije poput hiljada sitnih unosa, WAF treba odmah da odbaci takvu konekciju pre nego što stigne do samog veb servera.

4. Limitiranje memorije po procesima (Worker Processes)

U operativnom sistemu (npr. Debian/Ubuntu horda kroz cgroups ili sistemske limite) konfigurišite maksimalnu količinu memorije koju jedan radni proces (worker process) može da potroši. Na taj način, ukoliko napadač i pokrene HTTP/2 Bomb protiv jednog procesa, krahiraće samo taj proces (koji će se automatski restartovati), umesto da dođe do potpunog kolapsa operativnog sistema usled nedostatka RAM memorije.

Zaključak

HTTP/2 Bomb (CVE-2026-49975) predstavlja otrežnjujući podsetnik da evolucija protokola usmerenih na brzinu i performanse često sa sobom nosi skrivene arhitektonske zamke. Činjenica da je ovaj propust preživeo deset godina ljudskih provera, da bi ga na kraju otkrio AI model, šalje jasnu poruku o pravcu u kojem se kreće moderna ofanzivna i defanzivna bezbednost.

Za sistemske administratore i inženjere nema mesta čekanju – provera verzija servera i primena adekvatnih limita na HTTP/2 konekcije trenutno su najviši prioritet u održavanju stabilnosti mreže.