Containerd-sårbarheter: CVSS 8,8 rammer EKS/GKE [2026]

Fem nye sårbarheter i containerd, motoren som kjører de fleste Kubernetes-klynger i verden, ble bekreftet av AWS i et sikkerhetsbulletin datert 18. juni 2026. Den mest alvorlige, CVE-2026-50195, har en CVSS-score på 8,8 og lar en angriper forgifte bildecachen på delte noder for å kjøre kode i andres pods. Sammen med en sjette, separat sårbarhet fra mai samme år har containerd-prosjektet nå fått seks CVE-er i løpet av 2026 alene, flere enn i noe annet år siden prosjektet ble en del av Cloud Native Computing Foundation i 2017. Amazon EKS, Amazon ECS, Fargate, Bottlerocket og Google Kubernetes Engine er alle bekreftet berørt. Et Azure-bulletin med samme CVE-er er foreløpig ikke funnet, noe som i seg selv er en historie for nordiske IT-avdelinger som kjører AKS.

Hva er containerd, og hvorfor spiller det noen rolle

Containerd startet som en intern komponent i Docker, ble skilt ut som eget prosjekt i 2016 og donert til CNCF året etter. I dag er det standard kjøretidsmiljø for containere i de fleste moderne Kubernetes-distribusjoner, etter at prosjektet fjernet den innebygde Docker-integrasjonen (dockershim) fra og med versjon 1.24 i 2022. Når en pod starter i EKS, GKE eller AKS, er det som oftest containerd som henter avtrykket, setter opp filsystemet og starter selve prosessen på noden. Det gjør programvaren til noe av det mest kritiske i hele skystabelen, samtidig som svært få sluttbrukere noensinne ser navnet.

Nettopp fordi containerd sitter mellom Kubernetes og selve Linux-kjernen, får feil her sjelden konsekvenser bare for én container. En svakhet på dette laget kan bryte isolasjonen mellom pods på samme node, noe som er selve poenget med å kjøre delte klynger med flere kunder eller team i utgangspunktet. Det er derfor sikkerhetsmiljøet reagerer raskere på containerd-bugs enn på feil lenger opp i applikasjonslaget.

De seks sårbarhetene i containerd i 2026

GitHubs sikkerhetsdatabase for containerd-prosjektet viser fem separate advisories publisert 18. juni 2026, pluss en sjette fra 20. mai samme år. Til sammen dekker de versjonene 1.7 opp til 2.3, altså praktisk talt alt som kjørte i produksjon våren 2026. Tabellen under viser alle seks, hentet direkte fra containerd sine egne GitHub Security Advisories og AWS sitt sikkerhetsbulletin 2026-046.

CVE	CVSS	Kort beskrivelse	Krever spesialkonfig	Patchet i
CVE-2026-50195	8,8	Ubekreftede checkpoint-referanser forgifter bildecachen på delte noder, kan gi kjøring av kode på tvers av pods	Nei	2.1.9 / 2.2.5 / 2.3.2
CVE-2026-53488	8,3	LABEL-instruksjoner i et bilde videreføres urenset til containeren og kan kjøre kommandoer som root på verten	Nei	1.7.33 / 2.0.10 / 2.1.9 / 2.2.5 / 2.3.2
CVE-2026-53492	6,8	CDI-annotasjoner fra en gjenopprettet checkpoint stoles på uten validering, kan injisere enheter og monteringer fra verten	Ja, CDI må være aktivert	2.1.9 / 2.2.5 / 2.3.2
CVE-2026-53489	6,5	Symlenker i loggstier følges ikke sikkert ved checkpoint-gjenoppretting, gir lesetilgang til vertens filsystem	Ja, checkpoint/restore må være på	2.1.9 / 2.2.5 / 2.3.2
CVE-2026-47262	6,5	Et manipulert bilde kan utløse ukontrollert minnebruk og krasje containerd-prosessen på hele noden	Nei	1.7.33 / 2.0.10 / 2.1.9 / 2.2.5 / 2.3.2
CVE-2026-46680	Medium	En bruker-ID som ikke lar seg tolke som et 32-bits tall, blir feilaktig lest som et brukernavn, og omgår dermed Kubernetes sin runAsNonRoot-sperre	Nei	Rettet i påfølgende 1.7.x og 2.x-utgivelser

Forskeren Robert Prast krediteres for ansvarlig rapportering av CDI-svakheten (CVE-2026-53492) i containerd sin egen advisory. De to alvorligste feilene, cache-forgiftning og LABEL-injeksjon, krever ingen spesiell konfigurasjon for å utnyttes. Det er dette som gjør dem til noe hver eneste driftsteam med containerd i produksjon må ta stilling til, ikke bare de som bruker avanserte funksjoner som checkpoint/restore eller CDI-enheter for GPU-er.

Slik fungerer de to farligste angrepene

Cache-forgiftning på delte noder (CVE-2026-50195)

Denne feilen ligger i hvordan containerd sin CRI-plugin håndterer checkpoint-avbilder, altså øyeblikksbilder av kjørende containere som kan lagres og gjenopprettes senere. Fordi referansene i disse avbildene ikke ble validert riktig, kunne en bruker med rettigheter til å opprette pods på en node forgifte det delte bildecachen. Konsekvensen er at en annen pod på samme node, tilhørende en annen kunde eller et annet team, kan ende opp med å kjøre kode kontrollert av angriperen. På en delt Kubernetes-klynge, som er normen i de fleste EKS- og GKE-oppsett, betyr det i praksis at grensen mellom leietakere kan brytes uten at noen av dem gjorde noe galt i sin egen kode.

LABEL-injeksjon til root på verten (CVE-2026-53488)

Denne rammer et enda mer grunnleggende steg: selve nedlastingen av et container-bilde. Container-bilder kan inneholde LABEL-instruksjoner, metadata som normalt bare beskriver bildet. Feilen gjør at innholdet i disse LABEL-feltene ble ført videre til containeren uten sanering, og kunne dermed brukes til å kjøre vilkårlige kommandoer med rettigheter på selve vertsmaskinen. Angrepet krever verken checkpoint/restore eller andre spesialfunksjoner, bare at noen med tilgang til å starte en pod kan peke til et bilde de kontrollerer, for eksempel fra et offentlig register. Det er nettopp denne typen “bare et vanlig image pull” som gjør bugen alvorlig, fordi den ikke krever noen unormal handling fra offeret.

Historisk kontekst: 2026 er et rekordår for containerd

Containerd-prosjektets egen sikkerhetslogg på GitHub går tilbake til 2020, med den beryktede containerd-shim-svakheten CVE-2020-15257, som eksponerte et administrasjons-API mot containere med tilgang til vertens nettverk. Siden den gang har prosjektet i snitt hatt to til fire nye CVE-er per år. 2026 bryter mønsteret kraftig.

År	Antall CVE-er	Høyeste CVSS/alvorlighet	Eksempel
2020	2	Høy	CVE-2020-15257, shim-API eksponert mot vertsnettverk
2021	4	Høy	CVE-2021-21334, miljøvariabler lekket mellom containere
2022	4	Høy	CVE-2022-31030, minneutmatting via ExecSync
2023	2	Middels	CVE-2023-25153, minneutmatting ved import av OCI-bilde
2024	2	Høy	CVE-2024-40635, heltallsoverflyt i bruker-ID-håndtering
2025	3	Høy	CVE-2025-64329, minnelekkasje via Attach-funksjonalitet
2026	6	Kritisk (8,8)	CVE-2026-50195, cache-forgiftning på tvers av pods

Verdt å merke seg: CVE-2024-40635 fra i fjor, en heltallsoverflyt i den samme bruker-ID-håndteringen, er en direkte forløper til årets CVE-2026-46680. Det samme hjørnet av kodebasen er altså blitt angrepet to år på rad, noe som tyder på at området rundt bruker- og rettighetshåndtering i containerd fortsatt er skjørt, selv etter gjentatte runder med retting.

AWS, Google Cloud og Microsoft: ulik respons

De tre store skyleverandørene har håndtert avsløringen forskjellig, og forskjellene sier noe om hvor mye kontroll hver av dem faktisk har over egen infrastruktur.

Leverandør	Berørte tjenester	Offentlig bulletin	Leverandørens alvorlighetsgrad
AWS	EKS, ECS, Fargate, Bottlerocket, Amazon Linux	Ja, bulletin 2026-046, 18. juni 2026	Kritisk for de to mest alvorlige feilene
Google Cloud	GKE (alle nodepools med containerd)	Ja, egen GKE-sikkerhetsbulletin	Høy, ikke kritisk, fordi utnyttelse krever rettighet til å opprette pods
Microsoft Azure	AKS bruker containerd som standard kjøretid	Ikke funnet et eget AKS-bulletin med disse CVE-ene	Ukjent, ingen offentlig vurdering tilgjengelig

AWS og Google har begge publisert konkrete bulletiner med referanse til de samme fem CVE-ene fra juni. Google klassifiserer dem riktignok som “høy” heller enn “kritisk” i sitt eget system, fordi et vellykket angrep forutsetter at angriperen allerede kan opprette pods i klyngen, en forutsetning som demper risikoen for eksterne angripere, men ikke for interne trusselaktører eller kompromitterte CI/CD-pipeliner. Microsoft, derimot, har foreløpig ikke publisert et tilsvarende AKS-spesifikt bulletin som nevner disse CVE-ene ved navn, selv om AKS bruker containerd som standard kjøretid på samme måte som de to andre. Det betyr ikke nødvendigvis at AKS er upåvirket, bare at kommunikasjonen har vært mindre direkte enn hos AWS og Google.

Tidslinjen fra oppdagelse til patch

20. mai 2026: Containerd-prosjektet publiserer advisory for CVE-2026-46680, runAsNonRoot-omgåelsen.
18. juni 2026: Fem nye advisories publiseres samtidig for CVE-2026-50195, -53488, -53492, -53489 og -47262, sammen med rettede versjoner 1.7.33, 2.0.10, 2.1.9, 2.2.5 og 2.3.2.
18. juni 2026: AWS publiserer sikkerhetsbulletin 2026-046 samme dag, som bekrefter at EKS, ECS, Fargate, Bottlerocket og Amazon Linux er berørt.
Juni–juli 2026: Google Cloud publiserer sin egen GKE-sikkerhetsbulletin med samme fem CVE-er.
8. juli 2026: AWS sitt bulletin oversettes og publiseres på nytt for det tradisjonelle kinesiske markedet, et tegn på hvor bredt varselet er distribuert internasjonalt.
20.–21. august 2026: Sikkerhetsmiljøet, deriblant SecureWorld, omtaler fortsatt saken to måneder senere, et tegn på at patching tar tid i store, distribuerte klynger.

At det tar over to måneder fra patch til fortsatt aktiv mediedekning, er ikke unormalt for infrastrukturlaget. Node-oppgraderinger i store Kubernetes-klynger rulles typisk ut gradvis, gjerne over uker, for å unngå at hele klynger blir utilgjengelige samtidig. Det gir et reelt tidsvindu der sårbare noder fortsatt kjører i produksjon lenge etter at en rettelse finnes.

Hva sier ekspertene om containersikkerhet

Jimmy Mesta, teknologisjef i sikkerhetsselskapet KSOC, har pekt på et grunnleggende paradoks ved containere som isolasjonsmekanisme: “When done correctly, containers are a really strong security boundary. The problem is what does being done correctly really mean for your organization.” Det er en beskrivelse som passer godt på årets containerd-sårbarheter, der selve isolasjonen mellom pods er nøyaktig det som svikter når koden ikke gjør jobben sin riktig.

Mesta har også gitt et konkret, praktisk råd til team som ikke vet hvor de skal begynne: “Start with checking your workload configurations against the CIS benchmarks for Kubernetes.” Rådet er spesielt relevant nå, fordi mange av rettighetene som gjør cache-forgiftningsangrepet mulig, nettopp handler om hvor bredt tilgang til å opprette pods er delt ut i en klynge.

Kubernetes sin egen offisielle dokumentasjon er enda mer direkte om hvilken linje det er mellom en pod som er ordentlig avgrenset og en som ikke er det: “Enforce Pod security standards to ensure that Pods and their containers are isolated appropriately.” Rådet er ikke nytt, men årets containerd-hendelse viser at det fortsatt ikke er standardpraksis over alt, halvannet tiår etter at containere ble allemannseie i drift.

Markedspåvirkning for skyleverandørene

For AWS og Google Cloud er raske, konkrete bulletiner en måte å beholde tillit på i et marked der containerdrift er blitt en salgsvinnende faktor for enterprisekunder. Begge selskapene selger administrerte Kubernetes-tjenester nettopp på løftet om at de tar operasjonelt ansvar for kjøretidslaget, slik at kunden slipper å patche containerd selv på hver eneste node. Når det løftet testes av en reell sårbarhet, blir det synlig hvor fort hver leverandør faktisk beveger seg fra varsel til utbedring.

Microsofts stillhet, eller i det minste mangelen på et offentlig, navngitt AKS-bulletin for de samme CVE-ene, er den mer interessante forretningshistorien her. Azure har over flere år jobbet hardt for å ta markedsandeler fra AWS i bedriftssegmentet, delvis gjennom Nordic- og europeisk skysuverenitet-argumentasjon. En mindre transparent sikkerhetskommunikasjon på et område konkurrentene håndterer åpent, kan svekke akkurat det tillitsargumentet, uansett om AKS-klyngene faktisk ble patchet i bakgrunnen eller ikke. For kunder som driver compliance-tunge miljøer i bank, forsikring eller offentlig sektor i Norden, er dokumentert, navngitt sikkerhetskommunikasjon ofte like viktig som selve rettelsen.

Containerd mot andre kjøretidsmiljøer

Containerd er ikke det eneste alternativet for å kjøre containere under Kubernetes. CRI-O, utviklet av Red Hat-miljøet spesifikt for Kubernetes sitt Container Runtime Interface, er det vanligste alternativet, og brukes blant annet som standard i OpenShift. Docker Engine, som selv bygger på containerd under panseret, brukes fortsatt en del lokalt til utvikling, men er sjeldnere i produksjonsklynger etter at dockershim ble fjernet fra Kubernetes.

Det er verdt å understreke at CRI-O ikke automatisk er tryggere. Begge prosjektene deler mye av den samme underliggende kompleksiteten rundt bilde-håndtering, checkpoint/restore og rettighetsmodeller, og begge har hatt egne sikkerhetshendelser opp gjennom årene. Forskjellen ligger mer i hvor raskt og hvor åpent hvert prosjekt kommuniserer når noe går galt, samt hvor tett integrert kjøretiden er med den administrerte tjenesten kunden faktisk bruker. For en driftsingeniør er spørsmålet sjelden “hvilken kjøretid er hundre prosent trygg”, men heller “hvor raskt får jeg vite det, og hvor lett er det å oppgradere uten nedetid” når noe dukker opp.

Betydningen for norske og nordiske skybrukere

Norske og nordiske virksomheter som kjører containeriserte arbeidslaster i AWS, Google Cloud eller Azure, sitter i praksis i samme båt som resten av verden. Containerd-laget er identisk uansett hvilken region klyngen kjører i. Det som derimot skiller seg, er hvor mye kontroll den enkelte virksomhet faktisk har over patchesyklusen. Mange nordiske selskaper bruker administrerte node-grupper der skyleverandøren styrer oppgraderingstakten, mens andre, spesielt i finans og kritisk infrastruktur, kjører selvforvaltede noder der ansvaret for å oppdatere containerd ligger hos eget driftsteam.

For sistnevnte gruppe er anbefalingen enkel å formulere, men ikke alltid like enkel å gjennomføre raskt: sjekk containerd-versjonen på hver eneste node, og sammenlign mot de patchede versjonene 1.7.33, 2.0.10, 2.1.9, 2.2.5 og 2.3.2. Kommandoen under viser hvordan det gjøres direkte på en node som kjører containerd.

containerd --version
# Sammenlign utskriften mot patchede versjoner:
# 1.7.33  2.0.10  2.1.9  2.2.5  2.3.2
#
# I en Kubernetes-klynge, sjekk versjon på tvers av alle noder:
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.containerRuntimeVersion}{"\n"}{end}'

Fordi to av de fem sårbarhetene fra juni krever at checkpoint/restore eller CDI-funksjonalitet er aktivert, er et raskt mellomsteg for team som ikke rekker full patching umiddelbart å slå av disse funksjonene der de ikke faktisk er i bruk. Det stopper ikke de to alvorligste feilene, cache-forgiftningen og LABEL-injeksjonen, men reduserer angrepsflaten mens patchingen pågår.

Fem spådommer for containersikkerhet fremover

Flere bulletiner, raskere. Etter årets hendelse er det sannsynlig at både AWS og Google strammer inn tiden fra advisory til eget kundevarsel ytterligere, mens presset på Microsoft om å publisere tilsvarende åpent for AKS trolig øker.
Checkpoint/restore får strengere standardinnstillinger. To av de seks feilene i 2026 involverer nettopp denne funksjonen. Det er rimelig å vente at containerd-prosjektet vurderer å gjøre den mer restriktiv som standard, ikke bare bedre validert.
Bruker-ID-håndtering blir et eget innsatsområde. Med to år på rad med feil i samme kodeområde (2024 og 2026), peker mye mot en større opprydding eller omskriving av denne delen av containerd fremfor enda en punktrettelse.
Runtime-skanning blir standard i CI/CD, ikke bare i produksjon. Flere av årets feil utnyttes allerede ved et vanlig image pull, noe som gjør det mer attraktivt å fange opp sårbare containerd-versjoner før de når en klynge i det hele tatt.
Nordiske virksomheter med selvforvaltede noder får et press mot mer administrerte tjenester. Jo flere sårbarheter som krever manuell node-patching for å lukkes, desto sterkere blir argumentet for å la skyleverandøren ta ansvaret, selv om det betyr mindre kontroll over selve oppgraderingstakten.

Konklusjonen: infrastrukturlaget er fortsatt sårbart

Seks CVE-er på ett år, to av dem utnyttbare uten spesialkonfigurasjon og med CVSS-score over 8, er et tydelig signal om at containerd fortsatt har uløste utfordringer i kjernen av hvordan bilder og checkpoint-data håndteres. AWS og Google har svart med navngitte, offentlige bulletiner samme dag som advisoryene ble publisert. Microsoft har foreløpig ikke gjort det samme for AKS med akkurat disse CVE-ene, en forskjell som kan bli et konkurransefortrinn for de to andre i samtaler med sikkerhetsbevisste kunder. For driftsteam, uansett sky, er oppgaven den samme: sjekk versjonsnummeret på hver eneste node, oppgrader til 1.7.33, 2.0.10, 2.1.9, 2.2.5 eller 2.3.2, og ikke anta at “administrert tjeneste” automatisk betyr “allerede patchet”.

Ofte stilte spørsmål om containerd-sårbarhetene

Hvilke containerd-versjoner er berørt?

Versjonene 1.7 før 1.7.33, 2.0 før 2.0.10, 2.1 før 2.1.9, 2.2 før 2.2.5 og 2.3 før 2.3.2 er berørt av minst én av de fem CVE-ene fra juni 2026, ifølge containerd sine egne GitHub Security Advisories.

Er Amazon EKS berørt?

Ja. AWS sitt sikkerhetsbulletin 2026-046, publisert 18. juni 2026, bekrefter at Amazon EKS, ECS, Fargate, Bottlerocket og Amazon Linux alle er berørt av de samme CVE-ene.

Er Google Kubernetes Engine (GKE) berørt?

Ja. Google har publisert en egen GKE-sikkerhetsbulletin med de samme fem CVE-ene, klassifisert som “høy” alvorlighetsgrad fordi utnyttelse forutsetter at angriperen allerede kan opprette pods i klyngen.

Har Microsoft Azure og AKS publisert et tilsvarende bulletin?

Det er per 21. august 2026 ikke funnet et offentlig AKS-spesifikt sikkerhetsbulletin som navngir disse fem CVE-ene, selv om AKS bruker containerd som standard kjøretid på samme måte som EKS og GKE.

Hva er den mest alvorlige av de seks sårbarhetene?

CVE-2026-50195, med CVSS-score 8,8, regnes som mest alvorlig fordi den lar en angriper forgifte den delte bildecachen på en node og potensielt kjøre kode i andre brukeres pods, uten at det kreves noen spesiell konfigurasjon.

Må jeg gjøre noe hvis jeg bruker en administrert Kubernetes-tjeneste?

I mange administrerte oppsett håndterer skyleverandøren node-oppgraderingen automatisk, men det er likevel verdt å bekrefte versjonsnummeret manuelt, spesielt hvis klyngen bruker egendefinerte node-avbilder eller selvforvaltede nodegrupper der oppgraderinger ikke skjer automatisk.

Kan jeg beskytte meg uten å oppgradere containerd med en gang?

Delvis. Hvis du deaktiverer checkpoint/restore og CDI-funksjonalitet der de ikke er i bruk, reduserer du angrepsflaten for tre av de fem CVE-ene fra juni. De to mest alvorlige, cache-forgiftning og LABEL-injeksjon, krever imidlertid selve versjonsoppgraderingen for å lukkes fullt ut.

Hvorfor er 2026 et rekordår for containerd-sårbarheter?

Med seks CVE-er har containerd allerede i 2026 flere enn i noe tidligere år siden prosjektets sikkerhetslogg på GitHub startet i 2020. Deler av økningen henger sammen med at flere av årets feil ligger i nyere funksjonalitet som checkpoint/restore og CDI-støtte, kode som er yngre og mindre gjennomtestet enn kjernefunksjonene for å starte og stoppe containere.

Containerd-sårbarheter: CVSS 8,8 rammer EKS og GKE [2026]