Den 1. september 2026 publiserte sikkerhetsselskapet VulnCheck 22 nye CVE-oppføringer knyttet til Kubernetes-økosystemet. Seks av dem rammer Kyverno, en av de mest brukte policy-motorene i klynger verden over. Hullene spenner fra lekkasje av tjenestekontoer til SSRF-angrep som kan nå skyleverandørers metadata-tjenester, og ett av dem gjør det mulig å omgå håndhevede sikkerhetsregler helt. For norske og nordiske virksomheter som har bygget klyngedrift rundt skytjenester og policy-as-code de siste årene, er dette en påminnelse om at komponentene som skal håndheve sikkerhet, selv kan bli angrepsvei.
Hva skjedde 1. september 2026
VulnCheck opptrer som en anerkjent CVE Numbering Authority (CNA) og publiserer jevnlig samlede sårbarhetsrapporter for Kubernetes-relaterte prosjekter. Tirsdag 1. september 2026 la selskapet ut en gruppe på 22 CVE-numre i ett tak, ifølge Severity Daily. Seks av disse gjelder Kyverno, admission-kontrolleren og policy-motoren som CNCF gjorde til et gradert prosjekt i mars 2026. Resten av batchen dekker andre Kubernetes-nære komponenter, men det er Kyverno-funnene som har fått mest oppmerksomhet fordi de rammer et verktøy som kjører med utstrakte rettigheter midt i klyngens kontrollplan.
Det som gjør saken mer forvirrende enn vanlig, er at scoringen spriker mellom kildene. Severity Daily peker på at minst én CVE i batchen har fått både 3,7 og 9,3 i ulike sårbarhetsflater, avhengig av hvilken CVSS-vektor som er brukt. For driftsteam som prioriterer patching etter score alene, er det et konkret problem: to team som leser to forskjellige feeds kan ende opp med helt ulik hastegrad for samme hull.
De seks Kyverno-sårbarhetene i detalj
Fire av de seks sårbarhetene har fått egne CVE-numre med dokumenterte fikser i offentlige databaser. Tabellen under viser hva som er bekreftet så langt, basert på VulnCheck-rådgivningene og oppslag i NVD.
| CVE | Type | Beskrivelse | Fikset i versjon |
|---|---|---|---|
| CVE-2023-54356 | Svak kryptering | TLS-endepunkter støtter fortsatt 3DES-cifre, som gjør admission-kontrolleren sårbar for Sweet32-angrep | Fjernet i nyere 2026-utgivelser |
| CVE-2026-84195 | Token-lekkasje | Kyverno legger automatisk ved ServiceAccount-tokenet i utgående HTTP-kall via apiCall, uten eksplisitt autorisasjonsheader | 1.16.4 |
| CVE-2026-84196 | SSRF | SSRF i apiCall.service.url via variabelsubstitusjon, der svardata reflekteres i feilmeldinger og kan hentes ut | 1.18.0 |
| CVE-2026-84199 | Confused deputy / SSRF | apiCall kan nå skyleverandørers metadata-endepunkt (for eksempel 169.254.169.254) eller ressurser tilhørende andre leietakere | 1.16.2 |
| CVE-2026-84200 | Regelomgåelse | Når to PolicyExceptions overlapper, vinner den minst restriktive, slik at en håndhevet regel kan omgås | 1.13.0 |
Severity Daily skriver at et sjette hull i samme batch også gjelder apiCall-funksjonen, men detaljene og CVE-nummeret var ikke fullt ut publisert i kildene som er tilgjengelige ved skrivende stund. Mønsteret er likevel tydelig: fire av de fem bekreftede sakene handler om apiCall, funksjonen som lar Kyverno-policyer gjøre utgående HTTP-kall for å hente eller validere data under en admission-forespørsel.
Slik utnyttes token-lekkasjen
CVE-2026-84195 er den mest direkte av sakene. Når en Kyverno-policy bruker apiCall i servicemodus mot en ekstern URL, legger kontrolleren automatisk ved sitt eget ServiceAccount-token i forespørselen. Hvis en angriper klarer å styre eller omdirigere målet for kallet, kan tokenet havne hos en ekstern mottaker. Med det tokenet i hånden kan en angriper i prinsippet snakke med Kubernetes-API-et med Kyvernos egne rettigheter, som normalt er langt bredere enn en vanlig bruker har tilgang til.
SSRF mot skymetadata og andre leietakere
CVE-2026-84199 er kanskje den mest alvorlige i praksis, fordi den beskrives som et confused deputy-problem. apiCall kan trikses til å sende forespørsler mot interne adresser som skyleverandørenes metadata-tjeneste, ofte tilgjengelig på 169.254.169.254 i AWS, Azure og GCP. Klarer en angriper å nå dette endepunktet gjennom Kyverno, kan de hente ut midlertidige legitimasjonsdata for noden klyngen kjører på. I flerleietaker-miljøer åpner samme svakhet for at én kunde kan nå ressurser som tilhører en annen, avhengig av hvordan nettverket er segmentert.
Policy-omgåelse via PolicyExceptions
CVE-2026-84200 skiller seg fra de andre ved at den ikke krever nettverkstilgang i det hele tatt. Kyverno støtter såkalte PolicyExceptions, som lar administratorer definere unntak fra ellers strenge regler. Feilen ligger i rekkefølgen policyene evalueres i: hvis to unntak overlapper for samme ressurs, er det den minst restriktive som vinner. En bruker som vet at et bredt unntak finnes et sted i klyngen, kan da navngi eller merke ressursen sin slik at den treffer det unntaket, og dermed omgå en regel som i utgangspunktet skulle håndheves strengt. For team som har brukt PolicyExceptions til å løse akutte driftsproblemer og aldri ryddet opp igjen, er dette en stille bakdør.
Kyvernos sikkerhetshistorikk: ikke det første kritiske hullet
Kyverno har ikke hatt et rent rulleblad. Ifølge sårbarhetssporing sitert i researchen bak denne saken har prosjektet hatt 17 registrerte CVE-er totalt siden mars 2025, hvorav 14 er vurdert som høy eller kritisk alvorlighetsgrad. Blant de tyngste tidligere sakene:
| CVE | År | CVSS | Kort beskrivelse |
|---|---|---|---|
| CVE-2025-29778 | 2025 | 5,8 (Medium) | Ignorerer subjectRegExp og issuerRegExp i enkelte oppsett |
| CVE-2025-46342 | 2025 | 8,6 (Høy) | Omgåelse av policyregler via namespace-selektorer i match-betingelser |
| CVE-2025-47281 | 2025 | 7,7 (Høy) | Feil i JMESPath-variabelevaluering fører til tjenestenekt |
| CVE-2026-22039 | 2026 | 10,0 (Kritisk) | Rettighetseskalering på tvers av namespaces via apiCall i policyer |
| CVE-2026-23881 | 2026 | 7,7 (Høy) | Tjenestenekt via amplifisering av kontekstvariabler i policy-motoren |
| CVE-2026-40868 | 2026 | 8,1 (Høy) | Implisitt injisering av bearer-token lekker Kyvernos tjenestekonto-token |
Mønsteret er konsistent over tid: apiCall-funksjonen og policy-evalueringslogikken går igjen som kilde til de alvorligste feilene. CVE-2026-22039 fra tidligere i år, som fikk toppscore 10,0, handlet allerede om rettighetseskalering via nøyaktig samme funksjon som nå rammes igjen i september-batchen. Det tyder på at problemet ikke er en enkelt kodefeil, men en arkitektonisk risiko ved at en komponent med brede rettigheter tillater fritt konfigurerbare utgående nettverkskall.
Hvorfor admission-kontrollere er et yndet mål
Kyverno er langt fra alene om å bære denne typen risiko. Admission-kontrollere sitter i en unik posisjon: de ser og kan endre praktisk talt alle forespørsler om å opprette eller endre ressurser i en klynge, og de kjører derfor typisk med tilgangsnivåer som ligner klyngeadministratorens. Sikkerhetsselskapet Wiz dokumenterte i sin IngressNightmare-forskning hvordan en sårbarhet i ingress-nginx sin admission-kontroller kunne gi angripere tilgang til alle hemmeligheter på tvers av namespaces i en klynge. Wiz fant den gang rundt 6 500 klynger som eksponerte den sårbare kontrolleren direkte mot internett, inkludert hos flere Fortune 500-selskaper, ifølge omtale hos Hackaday og Cybersecurity Dive.
Kyverno-sakene og ingress-nginx-saken deler et fellestrekk: begge oppstår i komponenter som gjør nettverkskall eller tar imot data på vegne av klyngen, uten at det er strenge nok skiller mellom hva komponenten selv har lov til å gjøre og hva en bruker kan påvirke gjennom konfigurasjon. Vi har tidligere dekket lignende mønstre i containerd-sårbarhetene som rammet EKS og GKE og i AKS-hullet med CVSS 9,4. Det er ikke tilfeldig at disse sakene dukker opp med jevne mellomrom. Kontrollplanet i Kubernetes har mange bevegelige deler, og hver ny funksjon som gir mer fleksibilitet, som apiCall i Kyverno, øker samtidig angrepsflaten.
Kyverno vs OPA Gatekeeper: hvem er mest utsatt
Kyverno og OPA Gatekeeper er de to dominerende løsningene for policy-as-code i Kubernetes, men de er bygget svært forskjellig. Kyverno skriver policyer som vanlige Kubernetes-ressurser i YAML, supplert med CEL-uttrykk, og har innebygd støtte for å validere, endre (mutate), generere nye ressurser og verifisere image-signaturer. Gatekeeper bygger på det generelle rammeverket Open Policy Agent og bruker språket Rego, som gjør det mulig å gjenbruke samme policy-logikk utenfor Kubernetes, for eksempel mot Terraform-planer eller API-er.
| Egenskap | Kyverno | OPA Gatekeeper |
|---|---|---|
| Policyspråk | YAML + CEL | Rego |
| Læringskurve | Lav for team som kjenner Kubernetes fra før | Høyere, krever Rego-kompetanse |
| Mutering og generering | Innebygd og moden funksjonalitet | Delvis støtte, mer begrenset |
| Bruk utenfor Kubernetes | Begrenset, policyer er Kubernetes-ressurser | Bredt, samme Rego kan brukes flere steder |
| CNCF-status | Gradert prosjekt siden mars 2026 | OPA (kjernen) er gradert, Gatekeeper er en tilpasning |
| GitHub-stjerner (omtrentlig, 2025-2026) | Vokste fra rundt 2 900 til over 9 000 | Rundt 2 700 ved starten av 2025 |
Den lavere terskelen for å komme i gang har gjort Kyverno til førstevalget for mange team som allerede jobber tett med Kubernetes-YAML, og det forklarer noe av veksten fram mot CNCF-gradueringen. Samtidig betyr apiCall-funksjonaliteten som gir Kyverno mye av sin fleksibilitet, også at prosjektet har en bredere angrepsflate enn en løsning som i utgangspunktet ikke er designet for å gjøre egne utgående nettverkskall under evaluering av en policy. Gatekeeper har hatt færre alvorlige sårbarheter omtalt i offentlige kilder de siste to årene, men har til gjengjeld en brattere læringskurve som kan gjøre feilkonfigurasjon mer sannsynlig i praksis.
Kyvernos utbredelse: fra 574 til over 9 000 stjerner
Kyverno ble tatt opp som CNCF-prosjekt 10. november 2020, flyttet til inkubasjonsstadiet 13. juli 2022, og ble gradert prosjekt 16. mars 2026. I gradueringskunngjøringen fra CNCF heter det at fellesskapet rundt prosjektet «har vokst betydelig, fra 574 GitHub-stjerner til over 9 000», med bidragsytere og sluttbrukere over hele verden. Blant navngitte brukere som er trukket frem i forbindelse med gradueringen, er Bloomberg, Coinbase, LinkedIn, Vodafone, Deutsche Telekom, Spotify, Saxo Bank, det amerikanske forsvarsdepartementets Platform One og OVHcloud.
LinkedIn er blant selskapene som har delt konkrete driftstall: virksomheten oppgir å kjøre Kyverno mot over 20 000 admission-forespørsler i minuttet, fordelt på mer enn 230 klynger. Med adopsjon i den skalaen sier det seg selv at seks nye sårbarheter, uansett hvor raskt de patches, potensielt berører et stort antall produksjonsmiljøer samtidig. Flere av de navngitte adopterne, som Vodafone, Deutsche Telekom, Spotify og Saxo Bank, har direkte europeisk tilknytning, noe som gjør at europeiske og nordiske driftsteam har god grunn til å sjekke egne klynger mot listen over sårbare versjoner.
Konsekvenser for norske og nordiske virksomheter
Ingen av kildene som er tilgjengelige nå, navngir konkrete norske eller nordiske selskaper som er rammet av nettopp denne CVE-batchen. Det betyr ikke at risikoen er lav. Kyverno brukes av flere store europeiske teleselskaper og finansaktører, og mønsteret fra tidligere admission-kontroller-hendelser, som IngressNightmare, viser at eksponerte klynger sjelden er begrenset til ett geografisk område. For virksomheter som er underlagt NIS2-regelverket, som trådte i kraft i norsk rett gjennom digitalsikkerhetsloven, øker slike hendelser også presset på å dokumentere rask patching av kritisk infrastruktur.
Praktisk sett bør ethvert driftsteam med Kubernetes-klynger i drift, uavhengig av bransje, behandle dette som en vanlig patch-hendelse med forhøyet hastegrad, ikke som en ren PR-sak. Kombinasjonen av tokenlekkasje, SSRF mot metadata-tjenester og policy-omgåelse er akkurat den typen kjede en angriper trenger for å gå fra begrenset tilgang til fullt klyngekompromiss.
Markedet for Kubernetes-sikkerhet vokser raskere enn selve plattformen
Sårbarhetsbølgen kommer samtidig som markedet for verktøy som skal fange opp nettopp denne typen risiko, vokser kraftig. Anslagene spriker noe mellom analysehusene, men retningen er entydig.
| Kilde | Markedsstørrelse 2025 | Anslag 2026 | Langsiktig anslag | Årlig vekst (CAGR) |
|---|---|---|---|---|
| IMARC Group | 1,97 mrd. dollar | – | 10,3 mrd. dollar innen 2034 | 19,58 % |
| Straits Research | 2,19 mrd. dollar | 2,69 mrd. dollar | 14,05 mrd. dollar innen 2034 | 22,94 % |
| PW Market Research | 2,15 mrd. dollar | 2,61 mrd. dollar | 9,97 mrd. dollar innen 2032 | 24,5 % |
Uansett hvilket anslag man legger til grunn, peker alle tre rapportene mot en årlig vekst godt over 15 prosent for markedet som dekker container- og Kubernetes-sikkerhet, inkludert admission-kontroll og policy-motorer. Det er verdt å merke seg at policy-as-code-segmentet, der Kyverno og Gatekeeper hører hjemme, bare er én del av dette markedet, som også dekker skanning av images, kjøretidsbeskyttelse og nettverkssegmentering. Likevel er admission-kontroll blitt en selvsagt del av sikkerhetsgrunnlinjen i de fleste modne Kubernetes-oppsett, noe som gjør at hver ny CVE i akkurat dette laget får uforholdsmessig stor oppmerksomhet sammenlignet med sin tekniske kompleksitet.
Slik sjekker og oppdaterer du klyngen din
Første steg er å finne ut hvilken versjon av Kyverno som kjører i hver klynge. Det gjøres enkelt med kubectl:
kubectl get deployment kyverno-admission-controller -n kyverno -o jsonpath='{.spec.template.spec.containers[0].image}'Alle versjoner under 1.18.0 mangler minst én av fiksene som er nevnt over. Oppgraderingen bør gjøres til nyeste stabile 2026-utgivelse, ikke bare til minimumsversjonen som lukker enkeltsaken. Deretter bør apiCall-bruken gjennomgås spesifikt:
kubectl get clusterpolicies -o json | jq '.items[] | select(.spec.rules[].context[]?.apiCall != null) | .metadata.name'Denne kommandoen lister ut alle klyngepolicyer som faktisk bruker apiCall-funksjonen, slik at teamet kan prioritere gjennomgang av nettopp disse. For hver policy som er avdekket, bør man spørre om det utgående kallet må gå mot en ekstern adresse i det hele tatt, eller om det kan begrenses til interne tjenester med en eksplisitt tillatelsesliste. Videre bør alle PolicyExceptions i klyngen samles i én oversikt og kontrolleres for overlapp, siden det er nettopp overlappende unntak som utnyttes i CVE-2026-84200. Til slutt anbefales det å rotere ServiceAccount-tokenet til Kyverno-kontrolleren etter oppgradering, i tilfelle det allerede har vært eksponert, og å begrense Kyvernos RBAC-rettigheter til det minimum funksjonaliteten faktisk krever. For team som vil ha en bredere sjekkliste for selve klyngesikkerheten utover policy-motoren, har vi tidligere gått gjennom grunnleggende container-sikkerhet i Kubernetes steg for steg.
VulnCheck og CNCFs rolle i ansvarlig sårbarhetshåndtering
At en ekstern CNA som VulnCheck bidrar til å samle og offentliggjøre denne typen sårbarheter, er i seg selv et tegn på at Kubernetes-økosystemet har modnet sin sikkerhetsprosess. I forbindelse med Kyvernos CNCF-graduering ble det gjennomført en tredjeparts sikkerhetsrevisjon i samarbeid med CNCFs eget sikkerhetsutvalg (TAG Security and Compliance). Det betyr ikke at prosjektet er fritatt for feil, tallene over viser det motsatte, men det gir brukerne et sted å hente strukturert informasjon om hvilke versjoner som er trygge, i stedet for å stole på spredte blogginnlegg og forumtråder.
Det finnes foreløpig ingen offentlig uttalelse fra Kyverno-vedlikeholderne spesifikt om september-batchen i kildene som er gjennomgått til denne saken. Rådgivningene fra VulnCheck følger uansett en fast struktur: de oppgir berørt versjonsspenn, hvilken versjon som fjerner problemet, og en kort teknisk beskrivelse av angrepsveien, slik det fremgår av deres rådgivning for CVE-2026-84196 og tilsvarende for de andre sakene i batchen.
Konkurransebildet: sikkerhetsleverandørene som tjener på uroen
Hver ny bølge av Kubernetes-CVE-er styrker forretningscasen til leverandører som lever av å overvåke og lappe nettopp denne typen infrastruktur. Wiz, som allerede har bygget seg et navn på funn som IngressNightmare, er blant de mest synlige. Aqua Security, Sysdig og Palo Alto Networks sin Prisma Cloud tilbyr alle produkter som skanner klyngekonfigurasjon og admission-kontrollere for kjente svakheter, og de fleste av dem har trolig oppdatert sine signaturer for å fange opp Kyverno-versjonene som er nevnt i denne saken kort tid etter at VulnCheck publiserte funnene.
For Kyverno og OPA Gatekeeper selv er situasjonen litt mer ambivalent. En jevn strøm av CVE-er kan svekke tilliten til et enkeltprosjekt på kort sikt, men den kan også styrke argumentet for policy-as-code som konsept, siden hele poenget med slike motorer er å gjøre sikkerhetsregler eksplisitte, versjonerte og testbare. Prosjekter som håndterer sårbarheter åpent og raskt, slik Kyverno langt på vei har gjort med de fire bekreftede fiksene i september-batchen, kan komme styrket ut av det sammenlignet med løsninger der feil forblir udokumenterte.
Historisk kontekst: et gjentakende mønster i kontrollplanet
Kubernetes-økosystemet har sett lignende mønstre gjentatte ganger de siste tre årene. Vi har tidligere skrevet om en bølge av fire CVE-er i Kubernetes-verktøy med CVSS opptil 9,9, og om hvordan versjon 1.37 innførte tre brytende endringer som selskaper måtte forholde seg til samtidig som sikkerhetslappene rullet ut. Det som skiller Kyverno-saken fra flere av de tidligere, er at feilene ligger i selve håndhevingslaget, ikke i arbeidsbelastningene som kjører i klyngen. En sårbarhet i en applikasjonspod er alvorlig, men en sårbarhet i komponenten som skal håndheve sikkerhetspolicyer for alle podene, har et vesentlig større nedslagsfelt.
Dette føyer seg inn i et bredere bilde der stadig mer av Kubernetes’ egen sikkerhetslogikk flyttes inn i klyngen som kode, i stedet for å håndteres med eksterne skript eller manuelle rutiner. Det gjør driften mer forutsigbar i det daglige, men det betyr også at feil i disse motorene får konsekvenser på tvers av hele klyngen i stedet for å være isolert til én arbeidsbelastning.
Hva skjer videre: fem forventninger fremover
- Strengere standardinnstillinger for apiCall. Det er sannsynlig at Kyverno-prosjektet innfører strammere standardoppsett for utgående nettverkskall, med eksplisitt tillatelsesliste som standard i stedet for et opt-out-mønster.
- Flere CVE-er i konkurrerende policy-motorer. Når søkelyset først er rettet mot admission-kontrollere, er det rimelig å vente at forskere også gransker Gatekeeper og andre verktøy med samme grundighet i månedene som kommer.
- Fortsatt tosifret vekst i markedet for Kubernetes-sikkerhet. Med tre uavhengige analyser som alle spår en årlig vekst over 15 prosent frem mot 2032-2034, vil flere selskaper trolig innføre dedikerte verktøy for policy-skanning som eget budsjettpunkt.
- Tettere kobling mellom NIS2-etterlevelse og patch-hastighet. Virksomheter som omfattes av digitalsikkerhetsloven i Norge og tilsvarende regelverk i resten av Norden, vil trolig måtte dokumentere hvor raskt slike CVE-er lukkes, ikke bare at de til slutt blir lukket.
- Mer oppmerksomhet rundt CVSS-inkonsistens. Sprikende score for samme sårbarhet, slik man så i denne batchen, vil trolig føre til at flere sikkerhetsteam går bort fra å prioritere alene på CVSS-tall og i større grad vurderer faktisk utnyttbarhet i egen konfigurasjon.
Ofte stilte spørsmål
Hva er Kyverno?
Kyverno er en admission-kontroller og policy-motor for Kubernetes, gradert som CNCF-prosjekt i mars 2026. Den lar team skrive sikkerhets- og styringsregler som vanlige Kubernetes-ressurser i YAML, uten å måtte lære et eget policyspråk.
Hvor mange sårbarheter ble publisert 1. september 2026?
VulnCheck publiserte totalt 22 CVE-er knyttet til Kubernetes-nære komponenter samme dag, hvorav seks gjelder Kyverno spesifikt.
Hvilken Kyverno-versjon bør jeg kjøre for å være trygg?
Basert på de bekreftede fiksene bør klynger oppgraderes til minst versjon 1.18.0, som lukker CVE-2026-84196 og samtidig ligger over minimumskravene for de øvrige sakene (1.13.0, 1.16.2 og 1.16.4).
Er norske eller nordiske selskaper direkte rammet?
Ingen tilgjengelige kilder navngir konkrete norske eller nordiske ofre for akkurat denne CVE-batchen. Flere europeiske adoptere av Kyverno, som Vodafone, Deutsche Telekom og Saxo Bank, er imidlertid nevnt i CNCFs egne materialer, noe som tilsier at eksponeringen finnes i regionen.
Hva er forskjellen på Kyverno og OPA Gatekeeper?
Kyverno bruker YAML og CEL og er bygget spesifikt for Kubernetes, med sterk støtte for å endre og generere ressurser. Gatekeeper bygger på det generelle Rego-språket fra Open Policy Agent, som kan brukes utenfor Kubernetes også, men har en brattere læringskurve.
Er dette den første alvorlige sårbarheten i Kyverno?
Nei. Prosjektet har hatt 17 registrerte CVE-er siden mars 2025, hvorav 14 er vurdert som høy eller kritisk alvorlighetsgrad, inkludert en sak med toppscore 10,0 tidligere i 2026.
Hvordan finner jeg ut om klyngen min bruker apiCall?
Kjør en jq-basert gjennomgang av alle ClusterPolicies og let etter apiCall-feltet i kontekstdefinisjonene, slik det er vist i kommandoeksempelet lenger opp i artikkelen.
Hva bør jeg gjøre først hvis jeg drifter Kyverno i produksjon?
Oppgrader til nyeste stabile versjon, gjennomgå all bruk av apiCall og PolicyExceptions, roter ServiceAccount-tokenet til kontrolleren, og begrens Kyvernos RBAC-rettigheter til det funksjonaliteten faktisk trenger.
