En ny attack mot HTTP/2, kallad HTTP/2 Bomb, visar hur moderna webbprotokoll kan utnyttjas på oväntade sätt. Genom att missbruka komprimering och flödeskontroll kan en angripare få webbservrar som Nginx, Apache, IIS, Envoy och Pingora att snabbt förbruka stora mängder minne – i vissa fall på bara några sekunder.
En ny typ av överbelastningsattack mot HTTP/2 visar hur en till synes effektiv webbteknik kan vändas mot de servrar den är tänkt att hjälpa. Attacken kallas HTTP/2 Bomb och kan i värsta fall få stora webbservrar att snabbt förbruka enorma mängder minne.
Det handlar inte om ett klassiskt angrepp där angriparen skickar enorma datamängder mot en server. I stället utnyttjas funktioner som redan finns i HTTP/2-protokollet. Med relativt små mängder trafik kan en angripare få servern att lägga beslag på stora mängder RAM-minne. När minnet tar slut börjar tjänsten svara långsamt, krascha eller sluta svara helt.
Vad är HTTP/2?
HTTP är protokollet som webbläsare och webbservrar använder för att prata med varandra. När du öppnar en webbsida skickar webbläsaren förfrågningar till servern, som sedan svarar med HTML, bilder, skript, stilmallar och annan data.
HTTP/2 är en modernare version av HTTP. Den infördes för att göra webben snabbare och mer effektiv. Bland annat kan flera förfrågningar skickas över samma anslutning, och sidans olika delar kan hanteras mer parallellt än tidigare.
För vanliga användare betyder HTTP/2 oftast snabbare webbplatser. För serveradministratörer betyder det bättre prestanda – men också en mer komplicerad teknikstack.
Så fungerar HTTP/2 Bomb
HTTP/2 Bomb bygger på två delar som tillsammans blir farliga.
Den första delen handlar om HPACK, den metod som HTTP/2 använder för att komprimera HTTP-huvuden. Huvuden är metadata som skickas med varje webbförfrågan, exempelvis information om webbläsare, cookies, språk och vilken sida som efterfrågas.
Komprimering är normalt en bra sak. Den gör trafiken mindre och snabbare. Men i det här fallet kan angriparen skicka små komprimerade referenser som får servern att skapa betydligt större interna datastrukturer i minnet.
Den andra delen handlar om flödeskontroll i HTTP/2. Flödeskontroll används för att styra hur snabbt data får skickas mellan klient och server. Attacken utnyttjar detta för att få servern att hålla kvar svar och minnesobjekt längre än normalt.
Resultatet blir att servern tvingas reservera minne, men inte får möjlighet att frigöra det i tid. Attacken fungerar därför ungefär som att någon fyller ett lager med paket, men samtidigt blockerar utgången så att inget kan skickas vidare.
Varför är attacken allvarlig?
Det allvarliga är att attacken inte kräver extrem bandbredd. En angripare behöver inte nödvändigtvis ha ett stort botnät eller skicka enorma mängder trafik. Poängen är i stället att få servern att göra mycket mer arbete än klienten själv gör.
I tester har forskarna visat att flera välkända webbservrar och HTTP/2-implementationer kan pressas till mycket hög minnesanvändning på kort tid. Bland de berörda nämns Nginx, Apache HTTP Server, Microsoft IIS, Envoy och Cloudflare Pingora.
Det gör attacken särskilt oroande för publika webbplatser, API, lastbalanserare och reverse proxies som exponerar HTTP/2 direkt mot internet.
Problemet ligger inte bara i stora headers
Många skydd mot den här typen av attacker bygger på att begränsa hur stora HTTP-huvuden får vara. Det är logiskt: om en klient skickar för mycket metadata kan servern avvisa förfrågan.
Men HTTP/2 Bomb visar att det inte alltid räcker.
Attacken kan använda många små headerfält i stället för ett fåtal stora. Varje litet fält kan verka ofarligt, men tillsammans skapar de mycket intern hantering i servern. Minnesförbrukningen kommer alltså inte bara från den faktiska datamängden, utan även från serverns egna objekt, tabeller och bokföring.
Särskilt cookie-hantering har pekats ut som en faktor i vissa implementationer. HTTP/2 tillåter att Cookie-huvuden delas upp i flera fält. Om dessa inte räknas korrekt mot serverns gränser kan angriparen skapa väldigt många interna headerobjekt utan att slå i de skydd som administratören tror finns på plats.
Apache och Nginx har fått åtgärder
För Apache HTTP Server spåras problemet som CVE-2026-49975. En åtgärd finns i mod_http2 2.0.41, där cookie-huvuden räknas mot gränsen för antal tillåtna requestfält. För miljöer som inte kan uppgradera direkt rekommenderas att HTTP/2 tillfälligt stängs av med:
För Nginx har problemet åtgärdats i Nginx 1.29.8 genom en ny begränsning för maximalt antal headers. Den nya direktivet max_headers har ett standardvärde på 1000. För system där uppgradering inte är möjlig är en tillfällig åtgärd att stänga av HTTP/2:
Det är viktigt att se detta som tillfälliga skydd. Den långsiktiga lösningen är att uppdatera berörda komponenter när säkerhetsfixar finns tillgängliga.
Alla plattformar hade inte färdiga patchar direkt
Vid den första publiceringen fanns inte bekräftade patchar för alla berörda system. För IIS, Envoy och Cloudflare Pingora var läget mer oklart i samband med offentliggörandet. Senare uppgifter pekade på att Envoy hade släppt patchar, men att validering fortfarande pågick.
Det här visar ett återkommande problem i modern webbinfrastruktur: många tjänster är beroende av flera lager. En webbplats kan till exempel använda en CDN-tjänst, en reverse proxy, en lastbalanserare, en applikationsserver och ett internt API-lager. Alla dessa kan hantera HTTP/2 på olika sätt.
Därför räcker det inte alltid att bara uppdatera “webbservern”. Administratören måste förstå var HTTP/2 faktiskt termineras och vilka komponenter som tar emot trafiken direkt från internet.
Vad bör administratörer göra?
Den som driver publika HTTP/2-tjänster bör kontrollera om Nginx, Apache, IIS, Envoy, Pingora eller andra HTTP/2-komponenter används i kedjan.
Viktigast är att:
- uppdatera till versioner där tillgängliga fixar finns,
- införa tydliga gränser för antal headers per förfrågan,
- kontrollera att Cookie-huvuden räknas korrekt,
- övervaka ovanlig minnesanvändning,
- och tillfälligt stänga av HTTP/2 om ingen säker fix finns tillgänglig.
Att stänga av HTTP/2 kan påverka prestandan, men är i många fall bättre än att låta en publik tjänst vara sårbar för en attack som kan tömma serverns minne på kort tid.
En påminnelse om att snabbare inte alltid betyder säkrare
HTTP/2 Bomb är ett tydligt exempel på att optimeringar i protokoll kan få oväntade säkerhetskonsekvenser. Funktioner som komprimering, multiplexning och flödeskontroll är byggda för att göra webben snabbare och mer effektiv.
Men när samma funktioner kombineras på fel sätt kan de skapa asymmetri: klienten skickar lite data, medan servern tvingas reservera mycket minne och hålla kvar resurser länge.
Det är just den asymmetrin som gör HTTP/2 Bomb farlig. Attacken handlar inte om att skrika högst, utan om att få servern att arbeta ihjäl sig i tysthet.
För vanliga användare är detta inget man själv kan skydda sig mot i webbläsaren. För driftansvariga är budskapet däremot tydligt: kontrollera HTTP/2-konfigurationen, uppdatera berörda komponenter och se till att gränser för headers verkligen fungerar i praktiken.
https://www.openwall.com/lists/oss-security/2026/06/03/3
Faktaruta: HTTP/2 Bomb
Typ av hot: Denial-of-service-attack, DoS.
Berörda tekniker: HTTP/2, HPACK, flödeskontroll och hantering av HTTP-headers.
Berörda system: Nginx, Apache HTTP Server, Microsoft IIS, Envoy och Cloudflare Pingora.
Så fungerar attacken: Angriparen skickar små HTTP/2-förfrågningar som får servern att skapa och behålla stora mängder data i minnet.
Konsekvens: Servern kan snabbt få slut på RAM-minne och börja svara långsamt, krascha eller sluta svara helt.
Viktiga åtgärder: Uppdatera berörda komponenter, sätt tydliga gränser för antal headers och stäng tillfälligt av HTTP/2 om ingen säker fix finns.
Apache: Problemet spåras som CVE-2026-49975. Åtgärd finns i mod_http2 2.0.41.
Nginx: Åtgärdat i Nginx 1.29.8 med direktivet max_headers.
Rekommendation: Publika HTTP/2-tjänster bör kontrolleras och uppdateras så snart som möjligt.
