En svit kritiska brister i OpenSSL har satt IT-avdelningar i Sverige och övriga Norden i beredskapsläge. Mellan slutet av augusti och den 18 september 2026 har OpenSSL-projektet, Oracle, SUSE, Ubuntu och Debian rullat ut akuta säkerhetsuppdateringar för minst sju separata sårbarheter, varav flera bedöms som kritiska. Den allvarligaste, CVE-2026-63073, har fått en CVSS-poäng på 9,8 och beskrivs av granskare som möjlig att automatisera med total teknisk påverkan på drabbade servrar. Samtidigt har curl-projektet patchat en egen brist i hur biblioteket hanterar OpenSSL-anslutningar. För Sverige, där de flesta myndigheter, banker och molnleverantörer bygger sin TLS-infrastruktur på just OpenSSL, är det här inte en fotnot i ett changelog. Det är en patchningsvåg som berör praktiskt taget varje server som pratar HTTPS eller HTTP/3.
Vad har hänt: OpenSSL-krisen i korthet
Mellan den 25 augusti och den 18 september 2026 publicerade OpenSSL-projektet och flera stora Linux-distributioner en samordnad rad säkerhetsrådgivningar. Sammanlagt handlar det om sårbarheterna CVE-2026-75803, CVE-2026-63073, CVE-2026-63074, CVE-2026-63075, CVE-2026-63076, CVE-2026-14456 och CVE-2026-18798, plus en relaterad brist i curl, CVE-2026-80229. Branschmedier har beskrivit rullningen som en “massiv säkerhetssvep” över OpenSSL, nginx, rsync och delar av Linux-kärnans nätverksstack, med de flesta distributionsspecifika råden landade mellan 16 och 18 september. Fullständig lista över samtliga historiska och aktuella OpenSSL-brister finns i OpenSSL-projektets egen sårbarhetsöversikt.
Det som gör den här vågen ovanlig är bredden. Vanligtvis handlar en OpenSSL-uppdatering om en eller två buggar. Den här gången rör det sig om ett kluster där minst tre olika angreppsytor är inblandade samtidigt: kryptografisk autentisering (AEAD-chiffer), certifikathantering (CMP-protokollet) och den relativt nya QUIC-implementationen som ligger till grund för HTTP/3. Oracle Linux 9 fick sin rådgivning ELSA-2026-67165-0, som rebasade OpenSSL till version 3.5.8 och listade CVE-2026-14456, CVE-2026-14457, CVE-2026-18798, CVE-2026-54874 samt hela intervallet CVE-2026-63072 till CVE-2026-63076 som åtgärdade.
CVE-2026-75803: Kritisk autentiseringsbrist i AEAD-chiffer
Den mest uppmärksammade enskilda bristen är CVE-2026-75803, med en CVSS-poäng på 9,1. Felet sitter i hur OpenSSL hanterar dekryptering av tomma chiffertexter i AEAD-lägen som ChaCha20-Poly1305 och AES-OCB. När en applikation anropar funktionen EVP_Cipher() för att slutföra dekryptering av ett tomt meddelande kan biblioteket i vissa fall rapportera att autentiseringstaggen har verifierats korrekt, trots att så inte är fallet. Konsekvensen är att en förfalskad eller manipulerad post kan accepteras som äkta.
Det låter tekniskt, men effekten är konkret. AEAD-chiffer används för att både kryptera och autentisera trafik i ett svep, bland annat i TLS 1.3-sessioner och i API-anrop som förlitar sig på integritetsskydd snarare än bara sekretess. Om ett system litar blint på att en tom nyttolast har passerat autentiseringskontrollen öppnas en dörr för att smyga in förfalskad data i annars skyddade flöden. Sårbarheten träffar ett brett spann av versioner: OpenSSL från och med 3.0.0 upp till men inte inklusive 3.0.22, från 3.4.0 till 3.4.7, från 3.5.0 till 3.5.8, från 3.6.0 till 3.6.4 samt 4.0.0 till 4.0.2. Det täcker i praktiken alla grenar som byggts under de senaste tre åren, vilket är en av anledningarna till att felet klassas som kritiskt snarare än enbart högt. Den fullständiga tekniska beskrivningen finns registrerad i CVE-databasen hos MITRE och i Tenables sårbarhetsanalys.
CVE-2026-63073: CVSS 9,8 och risken för fjärrstyrning
Den högst rankade sårbarheten i hela klustret är CVE-2026-63073, med maximal allvarlighetsgrad på CVSS 9,8. CISA:s koordinatorer fattade sitt SSVC-beslut (Stakeholder-Specific Vulnerability Categorization) för bristen den 31 augusti 2026 och beskrev den som “automatable” med “total technical impact”, vilket i praktiken betyder att en attack kan skriptas och köras i stor skala utan mänsklig inblandning, och att en lyckad exploatering ger angriparen full kontroll över den drabbade OpenSSL-instansen. Samtidigt noterade koordinatorerna att man vid tidpunkten för beslutet inte hade sett bekräftade exploateringsförsök i verkliga miljöer.
Det är just den kombinationen, extremt hög teoretisk allvarlighetsgrad men ännu ingen känd aktiv exploatering, som gör att säkerhetsteam brottas med prioritering just nu. Ett CVSS-betyg på 9,8 placerar bristen i samma liga som några av de mest ökända sårbarheterna i modern internethistoria, men avsaknaden av bekräftade attacker gör att många organisationer riskerar att skjuta upp patchning till nästa ordinarie fönster. Med tanke på hur snabbt liknande brister historiskt har gått från teoretisk till aktivt utnyttjad avråder de flesta säkerhetsrådgivningar starkt från att vänta.
QUIC-sårbarheterna: När HTTP/3 blir en flaskhals
En stor del av det aktuella klustret handlar om OpenSSL:s relativt nya stöd för QUIC, transportprotokollet som ligger under HTTP/3. Fyra separata identifierare, CVE-2026-63074, CVE-2026-63075, CVE-2026-14456 och CVE-2026-18798, beskriver olika sätt att köra minnet i botten på en QUIC-tjänst.
CVE-2026-63074 handlar om Certificate Management Protocol, CMP, där OpenSSL cachar så kallade “extraCerts” från klientmeddelanden utan att någonsin rensa bort dem. En illvillig klient kan därmed tvinga fram obegränsad minnestillväxt på en server som kör CMP under lång tid, med minnesutmattning och tjänstavbrott som följd. Bristen träffar grenarna 4.0, 3.6, 3.5, 3.4 och 3.0, vilket enligt Ubuntus säkerhetsrådgivning gör den relevant för i princip varje tjänst som använder CMP för certifikathantering, inklusive företags-PKI som många nordiska organisationer driver internt.
CVE-2026-63075, publicerad den 25 augusti 2026, beskriver ett liknande mönster i själva QUIC-trafiken: en motpart som upprepade gånger skickar paket som kräver bekräftelse, men aldrig bekräftar de rena ACK-svaren tillbaka, tvingar fram minnestillväxt kopplad till anslutningen. Med många samtidiga QUIC-anslutningar, precis det scenario som moderna CDN:er och molnnativa applikationer bygger på, blir effekten en utmattningsattack som kan slå ut tjänsten utan att en enda byte känslig data läcker ut. CVE-2026-14456 beskriver en snarlik brist i hur en QUIC-server hanterar sin inkommande kanalkö, dokumenterad i SUSE:s rådgivning SUSE-2026-4039-1 från augusti 2026 och klassad som “Important”. Debians säkerhetsspårning har en motsvarande post för CVE-2026-63074 med status per distributionsgren. CVE-2026-18798 rör i sin tur en dubbel-frigöring, double free, i samma QUIC-kodväg.
curl och libcurl: Use-after-free i OpenSSL-providern
Parallellt med OpenSSL-klustret patchade curl-projektet sin egen sårbarhet, CVE-2026-80229, i september 2026. Felet sitter i hur libcurls så kallade multi-gränssnitt hanterar återanvända TLS-anslutningar. När en pool av anslutningar överlever längre än den ursprungliga “easy handle” som skapade dem kan OpenSSL:s bibliotekskontext frigöras medan en aktiv anslutning fortfarande håller en pekare till den, en klassisk use-after-free-bugg som kan leda till minneskorruption vid efterföljande I/O eller efter ett handslag.
Bristen träffar specifikt libcurl-installationer som kör mot OpenSSL 3:s providerkonfiguration, ett mönster som är vanligt i mikrotjänster och API-gateways med hög samtidighet, precis den typ av arkitektur som svenska molnbaserade tjänster i allt högre grad bygger på. Både OpenSSL och curl måste uppdateras samtidigt för att stänga hela kedjan, vilket komplicerar patchningen för team som hanterar de två biblioteken separat i sina byggpipelines. Den fullständiga tekniska rådgivningen finns hos curl-projektet, och team som tidigare täppte till CVE-2026-9545 i curl bör känna igen mönstret: flera separata TLS-relaterade curl-brister har dykt upp under samma år.
Sårbarheterna i sammanfattning
| CVE-ID | CVSS | Typ av brist | Publicerad | Status |
|---|---|---|---|---|
| CVE-2026-75803 | 9,1 | AEAD-autentiseringsbrist (ChaCha20-Poly1305/AES-OCB) | Aug/sept 2026 | Patchad, uppgradera till fixade delversioner |
| CVE-2026-63073 | 9,8 | Obehörig fjärrkontroll, “automatable” | SSVC-beslut 31 aug 2026 | Ingen bekräftad exploatering ännu |
| CVE-2026-63074 | – | CMP extraCerts, obegränsad minnestillväxt | Aug/sept 2026 | Patchad i 3.0–4.0 |
| CVE-2026-63075 | – | QUIC ACK-hantering, minnesutmattning (DoS) | 25 aug 2026 | Patchad i 3.4–4.0 |
| CVE-2026-14456 | – | QUIC inkommande kanalkö, DoS | SUSE-2026-4039-1, aug 2026 | Patchad |
| CVE-2026-18798 | – | QUIC double-free | Sept 2026 | Patchad |
| CVE-2026-80229 (curl) | – | Use-after-free i libcurl mot OpenSSL 3-provider | Sept 2026 | Patchad, uppdatera curl och OpenSSL tillsammans |
Streck i CVSS-kolumnen betyder att inget enhetligt betyg har publicerats i tillgängliga källor vid tidpunkten för den här artikeln. Det är ingen indikation på att bristen är mindre allvarlig, flera av dem beskrivs ändå som “Important” av leverantörer som SUSE.
Vilka plattformar och distributioner påverkas
Patchningsansvaret ligger inte bara hos OpenSSL-projektet centralt. Varje Linux-distribution som paketerar OpenSSL måste bygga om och släppa sina egna paket, vilket förklarar varför rådgivningarna har kommit i vågor under flera veckor snarare än på en enda dag.
| Distribution/produkt | Rådgivning | Ungefärlig tidpunkt | Åtgärd |
|---|---|---|---|
| Oracle Linux 9 | ELSA-2026-67165-0 | September 2026 | OpenSSL rebasad till 3.5.8 |
| SUSE Linux Enterprise | SUSE-2026-4039-1 | Augusti 2026 | Patch för CVE-2026-14456 med flera |
| Ubuntu (samtliga LTS-grenar) | USN-rådgivningar för 63074/63075 | Augusti–september 2026 | Patchar OpenSSL-grenar 3.0 till 4.0 |
| Debian | Security tracker-poster för 63074-serien | September 2026 | Patchning under utrullning per gren |
| curl/libcurl | CVE-2026-80229-rådgivning | September 2026 | Uppdatera till senaste libcurl-version |
För svenska organisationer som kör egna Linux-servrar, oavsett om det är på plats eller hos en molnleverantör, är den praktiska slutsatsen enkel: kontrollera vilken OpenSSL-version som faktiskt körs, inte bara vilken distributionsversion som är installerad. Ett vanligt misstag är att anta att senaste patcharna är installerade bara för att ett operativsystem är uppdaterat till senaste LTS-punktrelease, när själva OpenSSL-paketet kan ligga efter.
Så kontrollerar du om dina servrar är sårbara
Det första steget för alla team är att slå fast exakt vilken OpenSSL-version som körs i produktion, inklusive i containerbaser och färdiga images som kan bygga på äldre lager.
openssl version -a
# Debian/Ubuntu: lista installerad OpenSSL-version och kontrollera uppgraderingar
dpkg -l | grep openssl
apt list --upgradable 2>/dev/null | grep -i openssl
# RHEL/Oracle Linux: kontrollera paketversion mot rådgivningen
rpm -qa | grep openssl
# curl-version i samma körning
curl --version | head -n 1Om utdata visar en version inom något av de sårbara intervallen som listas i tabellen ovan är nästa steg att uppdatera paketet via distributionens pakethanterare och därefter starta om alla tjänster som länkar dynamiskt mot OpenSSL, inklusive webbservrar, applikationsservrar och egna binärer. Ett vanligt fallgrop är att glömma tjänster som startats innan uppdateringen och som fortfarande håller den gamla, sårbara versionen laddad i minnet tills de startas om. En genomgång av grunderna i HTTPS och TLS är en bra utgångspunkt för team som vill förstå varför just det här biblioteket är så centralt.
Historisk kontext: Från Heartbleed till dagens svit
OpenSSL har en lång historia av allvarliga sårbarheter som fått namn och egna loggor, med Heartbleed (CVE-2014-0160) från april 2014 som det mest kända exemplet. Den bristen läckte minnesinnehåll direkt från servrar och tvingade fram en av de största massuppdateringarna av digitala certifikat som internet skådat. Skillnaden mot dagens kluster är dels bredden, dels karaktären på bristerna. Där Heartbleed var en enskild, extremt allvarlig läcka av känslig data, är 2026 års svit en blandning av tjänsteavbrott (DoS), autentiseringsbrister och en potentiell fjärrkontrollrisk, spridda över flera olika delar av kodbasen samtidigt.
Det säger också något om hur OpenSSL-projektet har utvecklats. Tillägget av inbyggt QUIC-stöd, en relativt ny del av kodbasen jämfört med de decennier gamla TLS- och X.509-rutinerna, är den enskilt största källan till nya sårbarheter i årets rådgivningar. Ny kod i ett kritiskt bibliotek som OpenSSL innebär nästan alltid en period med fler upptäckta brister innan koden mognar, ett mönster som återkommit varje gång biblioteket fått stöd för ett nytt protokoll.
Konkurrentjämförelse: Hur står sig alternativen till OpenSSL?
Krisen har återupplivat en gammal diskussion: finns det skäl att byta bort OpenSSL till något av alternativen? Googles BoringSSL, som driver Chrome och stora delar av Android, är inte tänkt som en allmän ersättning eftersom Google explicit avråder externa projekt från att bero på dess API, som kan ändras utan förvarning. LibreSSL, OpenBSD-projektets forkning av OpenSSL efter Heartbleed 2014, har en mindre kodbas och en uttalad filosofi om att skala bort komplexitet, men saknar delar av funktionaliteten som moderna QUIC-tunga tjänster behöver. wolfSSL riktar sig främst mot inbyggda system och IoT-enheter med små minnesbudgetar, snarare än storskaliga molnmiljöer.
Slutsatsen för de flesta nordiska IT-avdelningar blir att ett byte av kryptobibliotek är opraktiskt på kort sikt. OpenSSL är djupt inbäddat i paketförråd, byggverktyg och tredjepartsbibliotek på ett sätt som gör en migrering till ett alternativ till ett flerårigt projekt snarare än ett svar på en enskild patchningsvåg. Det realistiska svaret är i stället snabbare patchcykler, bättre inventering av vilka versioner som faktiskt körs, och striktare separation mellan tjänster som exponerar QUIC/HTTP/3 och de som inte gör det.
Marknadspåverkan: Vad patchningsvågen kostar företag
Den direkta kostnaden för en OpenSSL-patchning är sällan licensavgiften, biblioteket är gratis och öppen källkod, utan tiden det tar att identifiera, testa och rulla ut uppdateringar över tusentals servrar, containerimages och byggpipelines utan att introducera regressioner. För större molnleverantörer och hostingbolag i Norden innebär det övertid för säkerhetsteam, extra CI/CD-körningar för att bygga om images med patchad OpenSSL, och i vissa fall tillfälliga kapacitetsbegränsningar när QUIC/HTTP/3-tjänster behöver startas om under kontrollerade former för att undvika de facto tjänstavbrott mot sig själva under omstarten.
Företag som redan har investerat i mjukvarusammansättningslistor (SBOM) och automatiserad sårbarhetsskanning av containerimages har ett tydligt försprång just nu. De kan slå upp exakt vilka tjänster som bygger på en sårbar OpenSSL-version på minuter i stället för dagar. Organisationer utan den insynen tvingas i praktiken göra en manuell inventering mitt under en pågående patchningsvåg, vilket ökar risken för att missa enstaka servrar eller äldre containerimages som ligger kvar i produktion.
Nordisk påverkan: Var är exponeringen störst?
Sverige, Norge, Danmark och Finland delar en infrastrukturprofil där en stor andel av offentlig sektor, bank och telekom kör Linux-baserade system med OpenSSL som standardbibliotek för TLS. Myndigheter som lutar sig mot Oracle Linux, SUSE eller Ubuntu i sina serverflottor omfattas direkt av de rådgivningar som redan finns tillgängliga, medan organisationer med äldre, egenbyggda system riskerar att sakna en tydlig patchväg om de använder OpenSSL-versioner som redan gått ur långsiktigt stöd.
QUIC-relaterade sårbarheter är extra relevanta för nordiska CDN- och streamingtjänster, som i allt högre grad har migrerat till HTTP/3 för att sänka latens mot mobila användare. En lyckad utnyttjning av minnestillväxtbristerna skulle kunna slå ut just de tjänster som marknadsförts som snabbare och mer tillförlitliga, en ironi som inte gått säkerhetsteam förbi.
Så patchar svenska IT-avdelningar rätt: Prioriteringsordning
- Inventera först: kartlägg alla system, containerimages och byggartefakter som länkar mot OpenSSL eller libcurl, inte bara de som ligger direkt exponerade mot internet.
- Prioritera CVE-2026-63073 (CVSS 9,8) och CVE-2026-75803 (CVSS 9,1) före DoS-bristerna, eftersom konsekvensen av en lyckad exploatering är betydligt allvarligare.
- Uppdatera OpenSSL och curl i samma ändringsfönster där båda används tillsammans, eftersom CVE-2026-80229 kräver att båda komponenterna är aktuella för att stänga hela kedjan.
- Testa omstarter av QUIC/HTTP/3-tjänster i en kontrollerad miljö innan produktionsutrullning, för att undvika att själva patchningen orsakar ett tillfälligt tjänstavbrott.
- Dokumentera vilka system som inte kunnat patchas direkt, och sätt kompenserande kontroller som hastighetsbegränsning av CMP- och QUIC-trafik i väntan på fullständig utrullning.
- Kör en TLS-härdningskontroll med testssl.sh efter patchning för att bekräfta att chiffersviter och protokollversioner ser ut som väntat.
Så bedömer säkerhetsbranschen läget
CISA:s koordinatorer klassade CVE-2026-63073 som “automatable” med “total technical impact” i sitt SSVC-beslut den 31 augusti 2026, samtidigt som man vid den tidpunkten inte hade sett bekräftade exploateringsförsök. SUSE valde att märka sin augustirådgivning SUSE-2026-4039-1 som “Important” snarare än “Critical”, en nivå som ändå räcker för att de flesta säkerhetspolicyer ska kräva patchning inom dagar snarare än veckor. Ubuntus säkerhetsteam har i sina separata rådgivningar för CVE-2026-63074 och CVE-2026-63075, publicerade via Ubuntus säkerhetsbulletiner, varit tydliga med att alla stödda grenar från 3.0 till 4.0 omfattas, vilket i praktiken lämnar mycket få installationer opåverkade. Organisationer som redan har en process för CISA KEV-patchhantering kan återanvända samma prioriteringsmodell för den här sviten, även om ingen av CVE:erna ännu ligger i själva KEV-katalogen.
Prognoser: Vad händer härnäst
- Fler distributionsspecifika rådgivningar väntas de kommande veckorna i takt med att mindre Linux-distributioner och BSD-varianter hinner ikapp med sina egna paketbyggen.
- CVE-2026-63073 riskerar att hamna i CISA:s katalog över kända utnyttjade sårbarheter om säkerhetsforskare lyckas bygga en fungerande exploateringskedja, vilket historiskt har hänt inom veckor för liknande högt rankade OpenSSL-brister.
- Fler QUIC-relaterade sårbarheter är sannolika under resten av 2026, eftersom koden fortfarande är relativt ny jämfört med OpenSSL:s äldre TLS-rutiner.
- Molnleverantörer kommer sannolikt att påskynda automatiserad patchning av basimages för att slippa upprepa manuella insatser vid nästa liknande händelse.
- Fler organisationer väntas investera i SBOM-verktyg och kontinuerlig sårbarhetsskanning som direkt svar på hur svårt det visat sig vara att snabbt kartlägga exponering i den här vågen.
Vanliga frågor om OpenSSL-sårbarheterna 2026
Är alla OpenSSL-versioner sårbara?
Nej. Sårbarheterna träffar olika versionsintervall beroende på CVE. CVE-2026-75803 påverkar exempelvis grenarna 3.0.0–3.0.21, 3.4.0–3.4.6, 3.5.0–3.5.7, 3.6.0–3.6.3 och 4.0.0–4.0.1, medan versioner från och med 3.0.22, 3.4.7, 3.5.8, 3.6.4 respektive 4.0.2 är patchade. Kontrollera alltid exakt version med openssl version -a innan du drar slutsatser.
Har någon av sårbarheterna utnyttjats aktivt?
Vid tidpunkten för CISA:s SSVC-beslut den 31 augusti 2026 fanns ingen bekräftad exploatering av CVE-2026-63073 i verkliga miljöer. Det kan ha förändrats sedan dess, så följ leverantörernas rådgivningar och CISA:s katalog över kända utnyttjade sårbarheter för uppdaterad status.
Räcker det att uppdatera operativsystemet?
Bara om distributionen redan har släppt en patchad OpenSSL-version och du faktiskt installerar den uppdateringen, samt startar om alla tjänster som länkar mot biblioteket. En generell systemuppdatering utan omstart av berörda tjänster lämnar den gamla, sårbara versionen laddad i minnet.
Påverkar det vanliga HTTPS-webbplatser?
Ja, i olika grad. AEAD-bristen i CVE-2026-75803 kan påverka appar och API:er som bygger på ChaCha20-Poly1305 eller AES-OCB för integritetsskydd, medan QUIC-bristerna primärt drabbar tjänster som redan har aktiverat HTTP/3. Klassisk TLS 1.2/1.3 över HTTP/1.1 och HTTP/2 påverkas i mindre utsträckning av just QUIC-delen av klustret.
Vad är skillnaden mot Heartbleed 2014?
Heartbleed (CVE-2014-0160) var en enskild, extremt allvarlig minnesläcka som exponerade känslig data direkt. 2026 års kluster är i stället en samling av flera olika typer av brister, från tjänstavbrott till en potentiell fjärrkontrollrisk, spridda över flera delar av kodbasen. Bredden gör patchningen mer komplex även om ingen enskild brist hittills matchar Heartbleeds omedelbara dataläckage.
Behöver jag patcha curl separat från OpenSSL?
Ja. CVE-2026-80229 sitter i libcurls hantering av anslutningspooler mot OpenSSL 3:s providerkonfiguration. Att bara uppdatera OpenSSL stänger inte den sårbarheten, du måste uppdatera libcurl till en patchad version också för att täppa till hela kedjan.
Hur vet jag om min molnleverantör redan har patchat?
Kontakta leverantörens säkerhets- eller statussida för information om patchstatus på hanterade tjänster. För infrastruktur du själv ansvarar för, till exempel egna virtuella maskiner eller containerimages byggda på leverantörens basimages, är det fortfarande ditt ansvar att verifiera OpenSSL-versionen och uppdatera vid behov. Fler grundläggande resurser om nätsäkerhet finns samlade på vår säkerhetsportal.
