Patcha curl CVE-2026-9545: TLS-guide 2026

Den 8 september 2026 publicerade curl-projektet en säkerhetsbulletin om CVE-2026-9545, en brist i libcurl som läcker data över HTTP/3 innan certifikatverifieringen hinner slå till. Samma vecka rapporterade CISA att 327 av sårbarheterna i deras KEV-katalog, motsvarande 20,2 procent, redan används i pågående utpressningskampanjer. För svenska och nordiska driftteam som kör curl i CI-pipelines, cronjobb och interna API-anrop är det här inte en teoretisk risk. Den här guiden går igenom exakt hur du hittar sårbara installationer, uppdaterar dem, och härdar TLS-konfigurationen så att samma typ av läcka blir svårare att utnyttja nästa gång. Du behöver grundläggande erfarenhet av Linux-terminalen, men varje steg är skrivet så att du kan kopiera och köra kommandona direkt.

Vad är CVE-2026-9545 och varför den är akut just nu

CVE-2026-9545 beskrivs av curl-projektet som en informationsläcka klassad enligt CWE-200 (exponering av känslig information till en obehörig aktör). Felet uppstår i ett specifikt scenario: libcurl gör en första transfer mot en riktig HTTP/3-server, cachelagrar en TLS-session, och gör sedan en andra transfer mot samma värdnamn. Om en angripare vid den andra anslutningen kan sätta sig mellan klient och server, till exempel via ett kapat nätverk eller en förfalskad DNS-post, kan libcurl skicka data på den nya anslutningen innan certifikatet har verifierats. Det är precis den situation TLS early data är känd för att skapa risker kring, och den är nu bekräftad i ett av världens mest använda nätverksbibliotek.

Bristen är inte universell. Den träffar bara HTTP/3-trafik som går via kombinationen ngtcp2 och nghttp3, och bara för webbadresser som börjar på https://. Kör du enbart HTTP/1.1 eller HTTP/2, eller använder en annan QUIC-backend, är du inte exponerad på samma sätt. Problemet är att många Linux-distributioner numera bygger curl med just ngtcp2 och nghttp3 som standard eftersom HTTP/3 har blivit vanligare i molntjänster och CDN:er. Både curl-kommandot och applikationer som länkar mot libcurl direkt påverkas, vilket gör att ett vanligt skript som kör curl i en pipeline kan vara lika sårbart som en stor applikationsserver.

Allvarligheten ligger inte i fjärrkodskörning, utan i att känslig data (tokens, sessionscookies, delar av request-headers) kan hamna hos fel mottagare under ett kort tidsfönster. I en miljö där curl används för att hämta hemligheter från ett secrets-API, ladda upp loggar eller kommunicera mellan mikrotjänster räcker det fönstret för att orsaka skada.

HTTP/3, QUIC och TLS early data i korthet

För att förstå varför buggen kunde uppstå behöver du en snabb bakgrund. HTTP/3 bygger på transportprotokollet QUIC istället för TCP. QUIC integrerar TLS 1.3 direkt i handskakningen, vilket gör anslutningar snabbare men också flyttar en del av ansvaret för att verifiera certifikat till ett tidigare skede i processen. TLS 1.3 introducerade dessutom “0-RTT”, eller early data, en funktion som låter en klient som redan pratat med en server skicka data direkt i det första paketet, utan att vänta på en fullständig handskakning.

Early data är snabbt, men det har ett känt designproblem: servern kan inte garantera att paketet inte är en uppspelning (replay) av ett tidigare paket, och klienten kan i vissa implementationer skicka data innan den nya anslutningens certifikat är verifierat mot rätt värdnamn. curl-projektets egen beskrivning av CVE-2026-9545 pekar exakt på det andra scenariot: en cachead TLS-session återanvänds mot en server som i verkligheten har bytts ut mot en angripares maskin, och libcurl hinner skicka iväg data innan felet upptäcks.

Det är värt att skilja på TLS early data i QUIC/HTTP3-sammanhang och den mer generella STARTTLS-relaterade bristen som beskrivs i CVE-2026-8286, där en ny transfer kan återanvända en befintlig anslutning trots att TLS-konfigurationen inte matchar. Den sårbarheten fick en CVSS 3.1-poäng på 8,1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) enligt Mitre och NVD, med hög påverkan på både konfidentialitet och integritet. Båda buggarna handlar i grunden om samma sak: TLS-lagret litar på en cachead eller återanvänd anslutning i ett skede där det borde göra en ny, fullständig verifiering.

Anledningen till att den här typen av bugg dyker upp just nu är att HTTP/3 och QUIC har gått från att vara experimentellt stöd till standardkonfiguration hos många CDN-leverantörer och molnleverantörer på kort tid. Ju fler bibliotek och applikationer som aktiverar 0-RTT-optimeringar för att pressa ner svarstider, desto fler tillfällen finns det för den här typen av race condition mellan cachad session och certifikatverifiering att uppstå. Det gäller inte bara curl. Samma klass av problem har historiskt dykt upp i flera QUIC-implementationer när protokollet varit relativt nytt, vilket är en av anledningarna till att curl-projektet valt att dokumentera scenariot så detaljerat i sin bulletin.

Vilka curl- och libcurl-versioner påverkas

Enligt curl-projektets officiella sida för CVE-2026-9545 är intervallet tydligt avgränsat. Version 8.11.0 till och med 8.20.0 är sårbara. Allt före 8.11.0 är opåverkat eftersom stödet för den relevanta HTTP/3-cachningsmekanismen inte fanns där ännu. Fixen landade i curl 8.21.0, vilket gör den versionen till målet för alla som ska patcha nu.

curl-version	Status	Rekommenderad åtgärd
Under 8.11.0	Inte påverkad av CVE-2026-9545	Fortsätt normal patchcykel
8.11.0 – 8.20.0	Sårbar (om ngtcp2 + nghttp3 används)	Uppgradera till 8.21.0 eller senare
8.21.0 och senare	Fixad	Verifiera versionen enligt steg 9
Byggd utan HTTP/3-stöd	Inte exponerad för denna specifika bugg	Uppdatera ändå för övriga säkerhetsfixar

Notera att versionsnumret i sig inte räcker för en fullständig bedömning. Två installationer med samma curl-version kan bete sig olika beroende på vilken TLS-backend och QUIC-implementation paketet är länkat mot. Det är därför steg 1 och 2 nedan handlar lika mycket om att kartlägga byggkonfigurationen som om att läsa av versionsnumret.

Container-images är ett eget kapitel i det här sammanhanget. En basbild som byggdes för sex månader sedan och sedan dess bara fått applikationskod lagd ovanpå kan mycket väl fortfarande innehålla en curl-version från intervallet 8.11.0–8.20.0, även om värdmaskinen som kör containern har en fräsch, patchad curl. Det är en av de vanligaste orsakerna till att organisationer tror sig vara skyddade men i praktiken fortfarande kör sårbar kod i produktion, eftersom sårbarhetsskanningar som bara tittar på värdnivå missar det som ligger inbakat i varje enskild image.

Förutsättningar innan du börjar

Guiden förutsätter att du har tillgång till ett Linux-, macOS- eller Windows-system med administratörsrättigheter. Testa gärna på en icke-produktionsmaskin först, eftersom en curl-uppgradering i vissa fall kan påverka andra paket som är länkade mot samma libcurl-bibliotek.

curl 8.20.0 eller äldre installerat (kontrolleras i steg 1)
Bash eller Zsh för Linux/macOS-kommandona, PowerShell 7 eller senare för Windows-delarna
Root- eller sudo-behörighet, alternativt lokal administratörsbehörighet på Windows
Git och en C-kompilator (gcc eller clang) om du behöver bygga från källkod i steg 7
Nginx 1.25 eller senare, eller motsvarande webbserver, om du ska genomföra TLS-härdningen i steg 10–11
Grundläggande vana vid att läsa loggutskrifter och tolka versionssträngar

Hanterar du fler än en handfull servrar, kör inventeringsstegen (1–2) via ett configuration management-verktyg som Ansible eller Puppet istället för manuellt. Kommandona nedan fungerar oavsett verktyg eftersom de bara läser lokal systeminformation.

Räkna med runt 20 minuter för inventeringen (steg 1–2) på en enskild server, 15–30 minuter för själva uppgraderingen beroende på plattform (steg 3–7), och ytterligare 20–30 minuter för verifiering och TLS-härdning (steg 8–11), om ni redan har en fungerande Nginx-konfiguration att utgå från. Automatiseringsstegen (12–13) tar längre tid att sätta upp första gången, men sparar in den tiden många gånger om vid nästa CVE. Sammanlagt landar en första genomgång på en enskild server oftast inom 60–90 minuter, medan en fullständig utrullning över en hel flotta styrs mer av antalet servrar och er befintliga automatiseringsmognad än av stegen i sig.

Steg 1–2: Inventera curl-installationer i din miljö

Första steget är att ta reda på exakt vilken version av curl som körs, och vilka bibliotek den är länkad mot. Kommandot curl --version ger dig båda delarna i en och samma utskrift, inklusive vilka protokoll och funktioner som är kompilerade in.

curl --version
# Exempelutskrift att leta efter:
# curl 8.18.0 (x86_64-pc-linux-gnu) libcurl/8.18.0 OpenSSL/3.5.0 ngtcp2/1.9.1 nghttp3/1.6.0
# Release-Date: 2026-04-02
# Protocols: dict file ftp ftps http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
# Features: alt-svc AsynchDNS HSTS HTTP2 HTTP3 HTTPS-proxy IPv6 Kerberos Largefile libz NTLM SSL threadsafe TLS-SRP UnixSockets

Två saker avgör om du är exponerad: versionsnumret på raden som börjar med “curl” och “libcurl”, samt om orden ngtcp2 och nghttp3 syns i utskriften. Saknas de orden byggdes din curl utan HTTP/3-stöd via den påverkade backend-kombinationen, och den akuta risken är lägre (fixen bör ändå installeras vid nästa patchfönster).

Steg två är att göra samma kontroll för varje applikation som länkar libcurl dynamiskt, inte bara för CLI-verktyget. På Debian- och Ubuntu-baserade system listar du vilka paket som beror på libcurl med kommandona nedan.

dpkg -l | grep libcurl
apt-cache rdepends libcurl4 | head -n 30
ldconfig -p | grep libcurl

På RHEL, Fedora eller AlmaLinux motsvaras detta av rpm -qa | grep libcurl och dnf repoquery --whatrequires libcurl. Spara utskriften i en textfil per server, så har du ett underlag att jämföra mot när patchningen är klar.

Steg 3–5: Uppdatera curl på Linux, macOS och Windows

På de flesta Linux-distributioner är den enklaste vägen att uppdatera via distributionens egen pakethanterare, förutsatt att en fixad build redan publicerats i din version av distributionen. Kontrollera alltid att den installerade versionen efteråt faktiskt är 8.21.0 eller senare, eftersom vissa distributioner backportar säkerhetsfixar utan att byta huvudversionsnummer.

# Debian / Ubuntu
sudo apt update
sudo apt install --only-upgrade curl libcurl4 libcurl4-openssl-dev
curl --version | head -n 1

# RHEL / Fedora / AlmaLinux
sudo dnf upgrade curl libcurl
curl --version | head -n 1

På macOS är förinstallerad curl kopplad till operativsystemet och uppdateras via Apples egna säkerhetsuppdateringar, som ofta ligger efter curl-projektets egen releasetakt. Snabbaste vägen till en aktuell version är Homebrew.

# macOS med Homebrew
brew update
brew upgrade curl
brew link curl --force
/opt/homebrew/opt/curl/bin/curl --version | head -n 1

På Windows beror uppdateringsvägen på hur curl installerades. Använder du winget kör du winget upgrade curl.curl i en PowerShell-terminal som administratör. Kör du curl via Git for Windows eller WSL uppdaterar du istället det underliggande paketet (Git-uppdateringen respektive WSL-distributionens pakethanterare enligt kommandona ovan). Kontrollera alltid resultatet med curl --version efteråt, oavsett plattform, eftersom flera curl-installationer ofta lever sida vid sida på samma maskin.

Tabellen nedan sammanfattar de vanligaste uppdateringsvägarna så att ni snabbt kan se vilket kommando som gäller för er miljö innan ni går vidare till att bygga från källkod i nästa avsnitt.

Plattform	Uppdateringskommando	Verifieringskommando
Debian / Ubuntu	apt install –only-upgrade curl libcurl4	curl –version
RHEL / Fedora / AlmaLinux	dnf upgrade curl libcurl	curl –version
macOS (Homebrew)	brew upgrade curl	brew list –versions curl
Windows (winget)	winget upgrade curl.curl	curl –version
Alpine (container)	apk update && apk upgrade curl	curl –version

Steg 6–7: Bygg och patcha curl från källkod när paket saknas

Vissa äldre distributioner, minimala containerbaser eller embedded-system har inte en färdig 8.21.0-build tillgänglig ännu. curl-projektet listar tre alternativ i sin bulletin: uppgradera, patcha och bygg om, eller inaktivera TLS early data helt. Måste du bygga från källkod, gör det i en isolerad build-miljö innan du rullar ut till produktion.

git clone --branch curl-8_21_0 --depth 1 https://github.com/curl/curl.git
cd curl
autoreconf -fi
./configure --with-openssl --with-ngtcp2 --with-nghttp3 --enable-alt-svc
make -j"$(nproc)"
sudo make install
sudo ldconfig
curl --version | head -n 1

Kräver organisationens policy att ni behåller den befintliga huvudversionen av curl av kompatibilitetsskäl, är alternativet att hämta enbart säkerhetspatchen från curl-projektets patch-arkiv och applicera den mot er befintliga källkodskopia med patch -p1 < cve-2026-9545.patch innan ni bygger om. Det alternativet kräver mer testning eftersom ni då underhåller en egen, icke-standardiserad build, vilket är anledningen till att curl-projektet listar det som andrahandsval efter en ren uppgradering.

Steg 8–9: Inaktivera TLS early data och verifiera fixen

Om en omedelbar uppgradering inte är möjlig, till exempel för att applikationen behöver regressionstestas innan produktionssättning, är den tredje mitigeringen att stänga av TLS early data för HTTP/3-trafiken. I curl gör du det genom att stänga av alt-svc-cachning, den mekanism som annars triggar återanvändningen av tidigare TLS-sessioner mot samma värdnamn.

Betrakta den här mitigeringen som ett plåster, inte som en lösning. Den tar bort prestandavinsten med 0-RTT för hela anslutningen, vilket i praktiken innebär att varje ny transfer måste göra om en fullständig handskakning. För de flesta interna verktyg och API-anrop är den kostnaden försumbar jämfört med risken, men för högfrekventa, latenskänsliga integrationer bör ni sätta ett tydligt datum för när mitigeringen ersätts av en riktig uppgradering till 8.21.0, snarare än att låta den bli en permanent konfiguration som ingen sedan följer upp.

# Stäng av alt-svc-cachning per anrop (tar bort återanvändningen av tidigare HTTP/3-sessioner)
curl --no-alt-svc https://exempel.se

# I ett C-program som länkar libcurl direkt:
curl_easy_setopt(handle, CURLOPT_ALTSVC, NULL);
curl_easy_setopt(handle, CURLOPT_SSL_ENABLE_ALPN, 1L);

Efter uppgradering, patchning eller mitigering behöver du verifiera att åtgärden faktiskt fungerar. Enklaste testet är att bekräfta versionsnumret och att HTTP/3-anropet fortfarande går igenom mot en betrodd testserver, utan att alt-svc-cachen längre återanvänder en gammal session mot fel värd.

curl --version | grep -E "curl 8\.(2[1-9]|[3-9][0-9])"
curl -v --http3 https://exempel.se 2>&1 | grep -i "alpn\|TLS"
echo "Visar utskriften curl 8.21.0 eller senare och en ny TLS-handskakning per anslutning, är fixen aktiv."

Steg 10–11: Härda TLS-konfigurationen enligt RFC 10015

Att patcha curl löser den akuta buggen, men det är ett bra tillfälle att också se över hela TLS-konfigurationen på servrarna som curl pratar med. IETF publicerade i augusti 2026 RFC 10015, som formellt förbjuder RSA-nyckelutbyte och klassisk (finite-field) Diffie-Hellman i TLS 1.2, och därmed tar bort över 175 cipher suites som tidigare ansågs standardkompatibla. TLS 1.2 i sig är inte förbjudet, men det måste konfigureras med ECDHE-baserade cipher suites för att räknas som säkert enligt de nya reglerna.

Cipher suite / mekanism	Status efter RFC 10015	Kommentar
RSA-nyckelutbyte (icke-PFS)	Förbjuden i TLS 1.2	Ger ingen forward secrecy, fasas ut helt
Klassisk DHE (finite-field Diffie-Hellman)	Förbjuden i TLS 1.2	Ersätts av ECDHE
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256	Fortsatt godkänd	Uppfyller PCI-DSS minimikrav
TLS 1.3 (samtliga standardsviter)	Rekommenderad baslinje	Bygger in forward secrecy som standard

I praktiken innebär det att ni behöver granska cipher-listan i varje reverse proxy och lastbalanserare, inte bara i klientbiblioteket curl. Ett Nginx-exempel som följer de nya reglerna, med enbart ECDHE-baserade sviter för TLS 1.2 och TLS 1.3 som förstahandsval, ser ut så här:

server {
    listen 443 ssl;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers on;
    ssl_ecdh_curve X25519:secp384r1;
}

Vill du testa hela cipher-uppsättningen mot en extern skanner istället för att läsa konfigurationsfilen manuellt, går metodiken igenom i vår guide till TLS-härdning med testssl.sh, som beskriver hur man tolkar en fullständig cipher-rapport steg för steg. Behöver ni utfärda nya certifikat i samband med härdningen finns processen i guiden om Let’s Encrypt och Certbot, och grunderna för nyckelhantering går vi igenom i artikeln om OpenSSL-nycklar och certifikat. Kör ni klient- och tjänst-till-tjänst-autentisering med ömsesidig TLS är det värt att också läsa vår guide om mTLS med Nginx, eftersom samma cipher-regler gäller där.

Steg 12–13: Automatisera skanning och kontinuerlig övervakning

En engångsuppdatering löser dagens problem men inte nästa CVE. Steg 12 är att bygga ett litet skript som kör inventeringen från steg 1–2 mot samtliga servrar regelbundet, så att avvikande versioner upptäcks innan de blir ett incidentärende. Nedan är ett exempel som går igenom en lista med värdnamn via SSH och rapporterar curl-versionen på varje.

#!/usr/bin/env bash
# curl-inventory.sh -- kör mot en lista servrar och flaggar sårbara versioner
set -euo pipefail
HOSTS_FILE="${1:-hosts.txt}"
FIXED_VERSION="8.21.0"

while read -r host; do
  version=$(ssh -o ConnectTimeout=5 "$host" "curl --version | head -n 1 | awk '{print \$2}'")
  if [ "$(printf '%s\n%s\n' "$FIXED_VERSION" "$version" | sort -V | head -n 1)" != "$FIXED_VERSION" ]; then
    echo "SÅRBAR: $host kör curl $version"
  else
    echo "OK: $host kör curl $version"
  fi
done < "$HOSTS_FILE"

Steg 13 är att koppla skriptet till schemaläggning, till exempel en cronjobb som kör varje natt och skickar rapporten till en Slack-kanal eller e-postlista via en enkel curl-anrop mot en webhook. Kombinera det gärna med den patchprocess som beskrivs i vår guide om CISA KEV-patchhantering, så att nya CVE:er som läggs till i CISA:s katalog automatiskt triggar en ny körning av inventeringsskriptet mot hela flottan.

Så minimerar ni driftstörningar under utrullningen

En curl-uppgradering låter enkel på pappret, men i en miljö med hundratals eller tusentals servrar är det skillnaden mellan en kontrollerad förändring och en självförvållad incident som avgör om patchningen går smidigt. Rulla aldrig ut en ny curl-version till hela flottan samtidigt. Välj istället en liten grupp servrar som representerar era vanligaste konfigurationer, till exempel en webbserver, en batch-jobbserver och en container-baserad mikrotjänst, och kör uppdateringen där först.

Låt canary-gruppen köra i minst ett par timmar under normal trafiklast innan ni går vidare. Håll extra koll på felmeddelanden kopplade till TLS-handskakningar, timeout-fel mot externa API:er och eventuella förändringar i svarstider för HTTP/3-trafik. Om något beter sig oväntat är det betydligt enklare att rulla tillbaka fem servrar än femhundra.

Ha alltid en tydlig återställningsplan innan ni börjar. Det enklaste är att behålla den gamla curl-binären eller paketfilen tillgänglig lokalt (till exempel i /opt/curl-backup/) så att ni snabbt kan växla tillbaka om en kritisk applikation visar sig bero på ett äldre beteende i libcurl. Dokumentera vilken exakt version ni går ifrån, inte bara vilken ni går till, så att en eventuell rollback är entydig även för någon som inte var med vid den ursprungliga patchningen.

Komplett fungerande exempel: patch-pipeline för curl i CI

Sätter du ihop stegen ovan till ett komplett, körbart projekt får du en pipeline som kan köras i valfritt CI-system (GitHub Actions, GitLab CI eller Jenkins). Nedan är ett fristående GitHub Actions-jobb som kontrollerar curl-versionen på build-agenten, uppgraderar vid behov, kör verifieringstestet och bryter bygget om en sårbar version fortfarande finns kvar efter uppgraderingsförsöket.

name: curl-cve-2026-9545-gate
on: [push, schedule]
jobs:
  verify-curl:
    runs-on: ubuntu-latest
    steps:
      - name: Kontrollera aktuell curl-version
        run: curl --version | head -n 1
      - name: Uppdatera curl till fixad version
        run: |
          sudo apt update
          sudo apt install --only-upgrade -y curl libcurl4
      - name: Blockera bygget om sårbar version kvarstår
        run: |
          VERSION=$(curl --version | head -n 1 | awk '{print $2}')
          FIXED="8.21.0"
          if [ "$(printf '%s\n%s\n' "$FIXED" "$VERSION" | sort -V | head -n 1)" != "$FIXED" ]; then
            echo "curl $VERSION är fortfarande sårbart mot CVE-2026-9545"
            exit 1
          fi
          echo "curl $VERSION är patchat"

Det här jobbet fungerar som en portvakt: bygget stoppas innan en sårbar curl-version hinner packas in i en container-image eller ett deploybart artefakt. Lägg till samma steg i era baseline-images för att undvika att problemet återkommer varje gång ett nytt lager byggs från en cachead basbild.

Kör ni GitLab CI istället för GitHub Actions är principen identisk: lägg versionskontrollen och uppgraderingen i ett eget stage före byggsteget, och låt jobbet returnera en icke-nollstatus om den kontrollerade versionen fortfarande faller inom det sårbara intervallet. Samma mönster går att återanvända i Jenkins genom ett shell-steg i en pipeline-fil, eller i Azure DevOps genom ett vanligt Bash-task. Poängen är att gaten ska ligga så tidigt som möjligt i kedjan, helst redan vid byggsteget, snarare än att upptäckas först vid en periodisk sårbarhetsskanning i produktion veckor senare.

Vanliga fallgropar när ni patchar CVE-2026-9545

Att bara uppdatera CLI-verktyget curl men glömma statiskt länkade applikationer som paketerar sin egen kopia av libcurl, till exempel vissa Python-wheels eller Go-binärer som bundlar C-bibliotek. Den sårbara koden ligger då kvar inbäddad i applikationen även om systemets curl är uppdaterat, och en vanlig apt upgrade rör aldrig vid den.
Att anta att distributionens standardrepo redan har 8.21.0 utan att kontrollera versionsnumret efter uppdateringen, särskilt på LTS-distributioner med långsammare patchcykler. Många LTS-varianter backportar bara säkerhetsfixen till en äldre huvudversion, vilket gör att ett skript som letar efter exakt "8.21.0" i versionssträngen kan ge falskt larm trots att fixen faktiskt finns på plats.
Att patcha applikationsservrar men glömma bort byggagenter, CI-runners och interna verktygsservrar där curl körs i skript men sällan syns i en vanlig tillgångsinventering. Den typen av maskiner saknar ofta ett CMDB-poster och blir därför osynliga tills någon aktivt söker efter dem.
Att stänga av TLS early data globalt utan att testa prestandapåverkan, vilket i vissa HTTP/3-tunga miljöer kan öka svarstider märkbart för klienter som tidigare drog nytta av 0-RTT. Behandla mitigeringen som en tillfällig brandvägg, inte som en permanent lösning.
Att härda cipher suites enligt RFC 10015 på webbservern men glömma interna tjänster som fortfarande tillåter RSA-nyckelutbyte i TLS 1.2, vilket gör hela härdningsinsatsen ofullständig. En angripare behöver bara hitta den svagaste länken i kedjan, inte den mest exponerade.
Att lita blint på ett versionsnummer utan att verifiera att paketet faktiskt är byggt mot ngtcp2 och nghttp3, vilket kan ge falsk trygghet om en organisation kör flera olika curl-builds parallellt. Två servrar med identiskt versionsnummer kan ändå ha helt olika riskprofil beroende på hur paketet kompilerades.
Att glömma att verifiera fixen i en riktig HTTP/3-anslutning efter uppgraderingen, och istället bara lita på att ett versionsnummer stämmer. Ett verktyg kan rapportera fel version om flera curl-installationer konkurrerar om samma sökväg, vilket gör att steg 9 i den här guiden inte är valfritt utan en obligatorisk kontrollpunkt.

Felsökning: när patchningen inte fungerar som förväntat

Även med tydliga steg dyker det upp specialfall. Här är de vanligaste problemen och hur du löser dem.

curl --version visar fortfarande gammal version efter apt upgrade. Kontrollera att ni inte har flera curl-binärer i PATH med which -a curl och att en gammal statisk build inte ligger tidigare i sökvägen.
Paketuppdateringen misslyckas med beroendekonflikt. Vissa paket låser en specifik libcurl-version. Kör apt-cache policy libcurl4 för att se vilka versioner som är tillgängliga, och håll koll på om ett tredjepartsrepo behöver aktiveras för den fixade versionen.
Byggfel vid kompilering från källkod (configure hittar inte ngtcp2). Installera utvecklingspaketen för ngtcp2 och nghttp3 separat, till exempel via apt install libngtcp2-dev libnghttp3-dev, innan ni kör configure på nytt.
Applikationen kraschar efter uppgraderingen. Kontrollera om applikationen är kompilerad mot ett specifikt API i libcurl som ändrats. Läs release-noterna för 8.21.0 innan ni rullar ut brett, och testa i en separat miljö först.
HTTP/3 slutar fungera helt efter att alt-svc stängts av. Det är förväntat beteende eftersom alt-svc-cachningen är en del av hur klienten upptäcker att en server stödjer HTTP/3. Om ni behöver behålla HTTP/3 men inte cachningen, uppgradera till 8.21.0 istället för att använda mitigeringen permanent.
Nginx startar inte efter cipher-ändringen. Kör nginx -t innan omstart för att fånga syntaxfel i cipher-listan, och kontrollera att OpenSSL-versionen på servern faktiskt stödjer alla angivna sviter.
Skanningsskriptet i steg 12 rapporterar fel version trots att servern är patchad. Kontrollera att SSH-sessionen inte använder en annan användares PATH med en äldre curl-binär, vilket är vanligt på servrar med flera parallella Python- eller Node-miljöer.
Klienter med äldre TLS-stackar kan inte längre ansluta efter härdningen. Om ni måste stödja äldre klienter tillfälligt, lägg till en explicit, tidsbegränsad ECDHE-baserad kompatibilitetssvit istället för att öppna upp för RSA-nyckelutbyte igen.
CI-jobbet i patch-pipelinen failar konsekvent på self-hosted runners. Kontrollera att runner-imagen faktiskt har tillgång till ett repo med 8.21.0, annars behöver ni bygga en egen baseline-image enligt steg 6–7 och referera den i CI-konfigurationen.
Versionen ser rätt ut i terminalen men containern som byggs innehåller ändå den gamla curl-versionen. Det beror oftast på att Docker-lagret med den gamla installationen ligger cachead. Bygg om med docker build --no-cache och kontrollera att Dockerfilen faktiskt uppdaterar paketlistan innan den installerar curl, inte bara refererar till en tidigare `apt update`-cache från en äldre bygglogg.
Två parallella TLS-bibliotek (OpenSSL och en annan backend) ger motstridiga cipher-listor. Kontrollera med curl --version vilket TLS-bibliotek som faktiskt är länkat, eftersom en cipher-lista konfigurerad för OpenSSL inte nödvändigtvis tolkas likadant av till exempel GnuTLS eller BoringSSL.

Avancerade tips för större miljöer

I större organisationer räcker det sällan att patcha en server i taget. Bygg istället in versionskontrollen av curl som en del av er befintliga golden image-process, så att varje ny virtuell maskin eller container redan har en fixad version från start. Container-baser som Alpine eller Debian-slim uppdateras ofta med fördröjning, så överväg att fastställa (pin) curl-versionen explicit i er Dockerfile istället för att lita på "senaste" i basbilden.

För organisationer som redan använder ett SBOM-flöde är det värt att lägga till en regel som specifikt flaggar libcurl-versioner mellan 8.11.0 och 8.20.0 i varje ny sammanställning, snarare än att förlita sig enbart på en generell CVE-databas som kan uppdateras med fördröjning. Kombinerat med signering av containerimages får ni ett spårbart bevis på exakt vilken curl-version som fanns i varje deployad artefakt, vilket är värdefullt både för internrevision och vid en eventuell incidentutredning.

Slutligen, om er organisation lyder under NIS2, är det värt att dokumentera hela patchcykeln (upptäckt, inventering, åtgärd, verifiering) som en del av det underlag ni ändå måste kunna visa upp vid en tillsyn. Det kostar marginellt mer tid nu men sparar betydligt mer vid en revision längre fram.

Ett annat vanligt förbisett område är interna nätverksverktyg som paketeras som del av övervakningslösningar, backup-agenter eller deployment-verktyg. Dessa uppdateras sällan i samma takt som operativsystemets kärnpaket eftersom leverantören måste testa och släppa en egen build. Håll en separat lista över tredjepartsprodukter som bundlar curl eller libcurl, och följ upp direkt med leverantören om en fixad version ännu inte publicerats. Vänta inte på nästa ordinarie uppdateringscykel om produkten hanterar internetvänd trafik.

Om ni driftar många Kubernetes-kluster är det värt att köra inventeringen från steg 12 som ett DaemonSet eller en CronJob istället för att SSH:a in manuellt på varje nod. Det ger samma resultat men skalar bättre när antalet noder växer, och gör det enkelt att exportera resultatet till samma observability-stack ni redan använder för annan drifthälsa.

Tänk också på att curl ofta finns med i init-containrar och sidecar-processer som körs för hälsokontroller eller för att hämta konfiguration vid uppstart. De processerna syns sällan i en vanlig applikationsinventering eftersom de bara kör under några sekunder innan huvudcontainern startar, men de exponerar exakt samma bibliotek och bör därför räknas in i samma patchcykel som resten av klustret.

Varför det här spelar roll för svenska och nordiska organisationer

FOI publicerade i januari 2026 rapporten "A review of cloud incidents and security controls" (FOI-R--5825--SE), som pekar ut en återkommande orsak till molnincidenter: publikt åtkomliga resurser som saknar tillräcklig accesskontroll eller misslyckas med att kryptera känslig information. En felkonfigurerad eller opatchad TLS-klient i en molnbaserad pipeline passar rakt in i den bilden, eftersom curl ofta är det verktyg som faktiskt flyttar data mellan tjänster i en sådan miljö.

Kopplingen till ransomware är heller inte långsökt. CISA:s KEV-katalog visade i en dataset publicerat i juni 2026 att 327 av de listade sårbarheterna, 20,2 procent, är flaggade som kända att användas i ransomware-kampanjer. En obeaktad TLS- eller HTTP-brist i ett internt verktyg är sällan huvudingången i en attack, men den är ofta det steg som gör att en angripare kan röra sig lateralt när de väl är inne, exempelvis genom att avlyssna eller manipulera trafik mellan interna tjänster.

För svenska bolag som redan omfattas av NIS2 och den svenska cybersäkerhetslagen är patchhantering av just den här typen av brist inte en valfri IT-uppgift utan en del av de rapporteringskrav som gäller vid en betydande incident. Att kunna visa att ni haft en process för att identifiera och åtgärda CVE-2026-9545 inom rimlig tid är därför både ett tekniskt och ett regulatoriskt argument för att prioritera stegen i den här guiden.

Många nordiska organisationer har dessutom en hög andel äldre infrastruktur som ursprungligen inte byggdes med HTTP/3 i åtanke, men som fått stödet på köpet via en distributionsuppgradering eller en ny version av ett tredjepartsverktyg utan att någon aktivt tog det beslutet. Det gör inventeringsstegen i den här guiden extra viktiga, eftersom risken annars är att HTTP/3-stödet, och därmed exponeringen mot CVE-2026-9545, glider in i miljön utan att stå med i något beslutsunderlag eller någon riskbedömning.

Vanliga frågor om CVE-2026-9545 och curl-patchning

Måste jag uppgradera curl om jag inte använder HTTP/3?
Om er build av curl inte är länkad mot ngtcp2 och nghttp3 är den akuta risken från just CVE-2026-9545 lägre, men ni bör ändå planera in uppgraderingen vid nästa ordinarie patchfönster eftersom andra säkerhetsfixar också ingår i nyare versioner.

Kan jag bara stänga av HTTP/3 istället för att patcha?
Det fungerar som en tillfällig mitigering eftersom bristen bara gäller HTTP/3-anslutningar via den drabbade backend-kombinationen, men det löser inte grundproblemet och bör bara användas som en kortsiktig åtgärd i väntan på en fullständig uppgradering.

Påverkar CVE-2026-9545 även Python-, Node.js- eller Go-applikationer?
Ja, om de använder ett bibliotek som i sin tur länkar mot systemets libcurl, till exempel via bindningar. Kontrollera vilken libcurl-version som faktiskt laddas i produktionsmiljön, inte bara vilken språkspecifik HTTP-klient som anges i beroendelistan.

Är TLS 1.2 osäkert efter RFC 10015?
Nej. TLS 1.2 är fortsatt tillåtet, men bara med ECDHE-baserade cipher suites. Det som förbjuds är RSA-nyckelutbyte och klassisk (finite-field) Diffie-Hellman, som saknar forward secrecy.

Hur vet jag om min organisation redan blivit utsatt för CVE-2026-9545?
Buggen kräver att en angripare aktivt kan manipulera nätverksvägen mellan klient och server vid rätt tillfälle, vilket gör den svår att upptäcka i efterhand utan detaljerad nätverksloggning. Om ni inte redan loggar TLS-handskakningar i detalj, prioritera patchningen snarare än att försöka bekräfta ett eventuellt tidigare intrång.

Behöver jag också åtgärda CVE-2026-8286 separat?
Ja. Det är en annan sårbarhet med en annan grundorsak (STARTTLS-relaterad återanvändning av anslutningar) även om den ligger nära CVE-2026-9545 tematiskt. Kontrollera separat vilka av era tjänster som förlitar sig på STARTTLS-uppgraderingar.

Räcker det att patcha bara internetexponerade servrar?
Nej. Interna tjänster som pratar med varandra via curl är minst lika viktiga att patcha, särskilt eftersom en angripare som redan tagit sig in i nätverket ofta rör sig lateralt via just sådan intern trafik.

Hur ofta bör jag köra inventeringsskriptet från steg 12?
En daglig eller nattlig körning är rimligt för de flesta organisationer, kombinerat med en extra körning varje gång en ny CVE kopplad till curl eller TLS publiceras.

Måste jag skanna container-images separat från värdservrarna?
Ja. En värdserver kan vara helt patchad medan en gammal container-image fortfarande innehåller en sårbar curl-version. Bygg in en versionskontroll i er image-pipeline, till exempel som en del av CI-jobbet beskrivet ovan, snarare än att bara skanna kör-miljön.

Patcha curl CVE-2026-9545: TLS-läcka i 12 Steg [2026]