• Stor säkerhetsuppdatering för Debian 13 täpper till 68 sårbarheter

    Debianprojektet har släppt en omfattande säkerhetsuppdatering för Debian 13 ”Trixie”. Uppdateringen rättar 68 säkerhetsproblem i Linuxkärnan, däribland brister som kan orsaka systemkrascher, informationsläckor och i vissa fall ge en angripare fullständig kontroll över datorn.

    Den nya uppdateringen publicerades den 31 juli 2026 och gäller Linuxkärnan 6.12 LTS, som används i Debian 13. Alla användare rekommenderas att installera uppdateringen så snart som möjligt.

    Säkerhetsuppdateringen kommer bara tio dagar efter Debians föregående kärnuppdatering. Den gången rättades 12 sårbarheter. Den nya uppdateringen är betydligt större och omfattar totalt 68 identifierade säkerhetsproblem.

    Vad är Linuxkärnan?

    Linuxkärnan är den centrala delen av operativsystemet. Den fungerar som en länk mellan datorns programvara och dess maskinvara.

    Kärnan hanterar bland annat:

    • processor och arbetsminne
    • hårddiskar och filsystem
    • nätverksanslutningar
    • USB-enheter
    • grafikkort
    • virtuella maskiner
    • användarnas behörigheter

    Ett säkerhetsfel i kärnan kan därför få större konsekvenser än ett fel i ett vanligt program. Om en angripare lyckas utnyttja en kärnsårbarhet kan personen i värsta fall få administratörsbehörighet och ta kontroll över hela systemet.

    Många mindre fel – men några är allvarliga

    De flesta av de 68 sårbarheterna är relativt begränsade och påverkar särskilda drivrutiner, nätverksfunktioner eller filsystem. Bland problemen finns fel som kan leda till felaktig minneshantering, åtkomst utanför tillåtna minnesområden och försök att använda minne som redan har frigjorts.

    Sådana tekniska fel kan bland annat orsaka:

    • systemkrascher
    • överbelastning av datorns resurser
    • informationsläckor
    • obehörig åtkomst
    • höjda användarbehörigheter

    En sårbarhet behöver inte vara enkel att utnyttja för att vara farlig. Många säkerhetsangrepp bygger på att flera mindre brister kombineras för att kringgå systemets skydd.

    Nätverksfel kan orsaka fjärrangrepp

    En av de allvarligaste sårbarheterna är CVE-2026-64530. Problemet finns i Linuxkärnans system för trafikstyrning, som används för att kontrollera och prioritera nätverkstrafik.

    Sårbarheten är ett så kallat use-after-free-fel. Det innebär att kärnan under vissa omständigheter försöker använda ett minnesområde efter att det redan har frigjorts.

    Felet kan orsaka en fjärrutlöst överbelastningsattack, så kallad denial-of-service. Det finns dessutom en möjlig risk för att sårbarheten skulle kunna användas för att köra skadlig kod på den angripna datorn.

    Open vSwitch-fel kan ge rootbehörighet

    Ett annat allvarligt problem är CVE-2026-64531, även kallat OVSwrap. Sårbarheten finns i datapath-funktionen för Open vSwitch.

    Open vSwitch är en virtuell nätverksswitch som ofta används i servrar, molnplattformar, containermiljöer och virtualiserade system.

    En lokal användare som lyckas utnyttja sårbarheten kan höja sina behörigheter och få tillgång till systemets rootkonto. Root är den högsta behörighetsnivån i Linux och ger i praktiken fullständig kontroll över operativsystemet.

    Sårbarheten är framför allt relevant för servrar och system där flera användare, virtuella maskiner eller containrar delar samma maskin.

    Manipulerade NTFS-diskar kan krascha systemet

    Två andra sårbarheter, CVE-2026-64532 och CVE-2026-64533, finns i Linuxkärnans NTFS3-drivrutin.

    NTFS är det filsystem som normalt används av moderna Windowsinstallationer. Linux kan läsa och skriva till NTFS-formaterade hårddiskar och USB-minnen med hjälp av särskilda drivrutiner.

    Sårbarheterna kan utlösas när systemet monterar ett särskilt manipulerat NTFS-filsystem. En angripare skulle exempelvis kunna förbereda ett USB-minne eller en avbildningsfil som får datorn att krascha när innehållet öppnas.

    Felen kan även orsaka minnesskador eller läckage av information från systemets minne.

    Även lagring och virtuella maskiner påverkas

    Uppdateringen rättar också två fel i NVMe over TCP, en teknik som gör det möjligt att använda snabba NVMe-lagringsenheter över ett nätverk.

    Sårbarheterna CVE-2026-64534 och CVE-2026-64535 kan orsaka överbelastning och göra att tjänsten eller hela systemet slutar fungera.

    Dessutom rättas CVE-2026-53365, som finns i virtio-vsock. Funktionen används för kommunikation mellan en fysisk värddator och virtuella maskiner.

    En virtuell gästmaskin kan under vissa förhållanden skicka stora meddelanden utan att resurserna frigörs korrekt. Med tiden kan värddatorns resurser förbrukas, vilket kan leda till kraftigt försämrad prestanda eller systemstopp.

    Uppdatera Debian 13 så snart som möjligt

    Alla som använder Debian 13 ”Trixie” bör installera de senaste uppdateringarna. Det gäller både skrivbordsdatorer, bärbara datorer och servrar.

    Öppna en terminal och kör:

    sudo apt update
    sudo apt full-upgrade
    

    När den nya kärnan har installerats måste datorn startas om:

    sudo reboot
    

    Uppdateringen installerar Linuxkärnan 6.12.100-1.

    Efter omstarten går det att kontrollera vilken kärna som används med:

    uname -r
    

    Det är viktigt att komma ihåg att en ny kärna inte börjar användas direkt efter installationen. Den aktiveras först när datorn har startats om.

    Regelbundna uppdateringar är det viktigaste skyddet

    Det finns inga uppgifter om att alla de rättade sårbarheterna aktivt utnyttjas i omfattande attacker. När tekniska detaljer om säkerhetsfel blir offentliga ökar dock risken för att angripare utvecklar metoder för att utnyttja dem.

    Att regelbundet installera säkerhetsuppdateringar är därför ett av de enklaste och mest effektiva sätten att skydda ett Linuxsystem.

    För Debian 13-användare är rekommendationen tydlig: installera uppdateringen och starta om datorn så snart det är praktiskt möjligt.

    https://lists.debian.org/debian-security-announce/2026/msg00316.html

    root@debian:~# säkerhetsrapport

    [ SYSTEM ] Debian 13 “Trixie”

    [ KERNEL ] Linux 6.12 LTS

    [ UPPDATERAD VERSION ] 6.12.100-1

    [ PUBLICERAD ] 31 juli 2026

    [ SÅRBARHETER ] 68 rättade säkerhetsproblem

    [ RISKER ] Privilegiehöjning, informationsläckor, minnesfel och överbelastningsattacker

    [ ALLVARLIGA FEL ] CVE-2026-64530 och CVE-2026-64531

    [ PÅVERKADE OMRÅDEN ] Nätverk, Open vSwitch, NTFS3, NVMe over TCP och virtio-vsock

    sudo apt update sudo apt full-upgrade sudo reboot

    [ VARNING ] Den nya kärnan börjar användas först efter omstart.

    root@debian:~# uname -r

  • HTTP/2 Bomb – ny attack kan få webbservrar att krokna på sekunder

    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.

Etikett: denial of service

  • Stor säkerhetsuppdatering för Debian 13 täpper till 68 sårbarheter

    Debianprojektet har släppt en omfattande säkerhetsuppdatering för Debian 13 ”Trixie”. Uppdateringen rättar 68 säkerhetsproblem i Linuxkärnan, däribland brister som kan orsaka systemkrascher, informationsläckor och i vissa fall ge en angripare fullständig kontroll över datorn. Den nya uppdateringen publicerades den 31 juli 2026 och gäller Linuxkärnan 6.12 LTS, som används i Debian 13. Alla användare rekommenderas…

  • HTTP/2 Bomb – ny attack kan få webbservrar att krokna på sekunder

    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…