På ti dager i august 2026 fikk Kubernetes-økosystemet fire nye sårbarheter, og de rammet ikke selve klyngen. De rammet verktøyene som skal styre og sikre den. Red Hat sitt Multicluster Engine fikk en SSRF-feil med CVSS 9,3. Databaseoperatøren CloudNativePG fikk en privilegie-eskalering med CVSS 9,4. Og sikkerhetsskanneren Prowler, som brukes av titusenvis av team til å lete etter nettopp denne typen feil, fikk selv en kommandoinjeksjon med CVSS 9,9 (OpenCVE). Det er den høyeste alvorlighetsgraden av de fire.
Ingen av feilene er bekreftet utnyttet i praksis ennå. Men mønsteret er tydelig, og det bekymrer sikkerhetsmiljøet mer enn hver enkelt sårbarhet gjør alene. Styringslaget, altså verktøyene organisasjoner installerer for å administrere flere klynger, kjøre databaser i containere og revidere sikkerhetstilstanden i skyen, har blitt et eget angrepsmål. For norske og nordiske virksomheter som har flyttet stadig mer drift til Kubernetes de siste årene, er dette en påminnelse om at sikkerhetsverktøyet i seg selv kan være det svakeste leddet.
Fire sårbarheter på ti dager: dette skjedde i august 2026
Tidslinjen er kort og tett. Den 12. august publiserte Prowler-teamet en rettelse for CVE-2026-73263, en kommandoinjeksjon i verktøyets Kubernetes-tilkoblingstest. Én uke senere, 19. august, fulgte Red Hat opp med CVE-2026-66794 i Multicluster Engine for Kubernetes (MCE). Dagen etter, 20. august, kom CVE-2026-55769 i CloudNativePG, PostgreSQL-operatøren som titusenvis av klynger bruker til å kjøre databaser direkte i Kubernetes. Samme uke ble også CVE-2026-35469, en denial-of-service-feil i kubelet, CRI-O og kube-apiserver, formelt lagt til den offisielle Kubernetes-sårbarhetslisten (kubernetes.io).
Det er ikke tilfeldig at disse sakene dukket opp samtidig. Sikkerhetsforskere bruker i økende grad automatiserte kodegjennomganger, deriblant AI-assistert statisk analyse, til å gå gjennom modne open source-prosjekter på nytt. Oppdagelsen av MCE-feilen ble for eksempel kreditert et internt Red Hat-initiativ kalt «Project Glasswing», som kjørte AI-basert statisk sikkerhetsanalyse (SAST) mot kildekoden til cluster-proxy-addon. Det samme mønsteret, eldre kode som aldri har vært gjennom en systematisk sikkerhetsrevisjon før nå, går igjen i flere av de fire sakene.
Fellesnevneren er verdt å understreke: ingen av de fire komponentene kjører selve applikasjonene dine. De styrer, overvåker eller reviderer klyngene som gjør det. Det gjør konsekvensene annerledes enn en vanlig applikasjonssårbarhet. Et vellykket angrep her kan gi tilgang på tvers av flere klynger samtidig, ikke bare én.
Red Hat Multicluster Engine: SSRF med CVSS 9,3 åpner klyngene dine
Multicluster Engine for Kubernetes er komponenten Red Hat bruker til å la ett kontrollpunkt («hub») administrere mange OpenShift- og Kubernetes-klynger samtidig. Den er også fundamentet i Red Hat Advanced Cluster Management (RHACM), så enhver organisasjon som kjører RHACM med cluster-proxy-addon aktivert, arver eksponeringen automatisk (Red Hat).
Feilen, katalogisert som CVE-2026-66794 med CVSS 9,3, ligger i hvordan proxyens brukervendte Route håndterer forespørsler. Den bygger målserverens adresse direkte fra URL-stier som brukeren kontrollerer, uten å sjekke autentisering eller autorisasjon. Resultatet er en klassisk SSRF-sårbarhet (server-side request forgery): en angriper som når fram til Route-en, kan bruke den til å nå interne tjenester på hvilken som helst administrert klynge tilknyttet hub-en. Red Hat har foreløpig ikke oppgitt konkrete versjonsnumre for patchede utgaver, men anbefaler organisasjoner å oppgradere så snart en fikset versjon er tilgjengelig, og i mellomtiden begrense nettverkstilgangen til Route-en til betrodde kilder.
Skalaen er det som gjør dette interessant fra et risikoperspektiv. Red Hats eget datablad for Advanced Cluster Management oppgir at én enkelt hub kan administrere opptil 3 500 OpenShift-klynger (Red Hat). Det tallet er en kapasitetsgrense, ikke et bevis på faktisk bruk i felten, men det illustrerer hvorfor en enkelt SSRF-feil i styringslaget er mer alvorlig enn en tilsvarende feil i én enkelt applikasjon. Én kompromittert hub kan i prinsippet gi innsyn i tusenvis av klynger.
Ingen offentlig kilde melder om aktiv utnyttelse av CVE-2026-66794 per slutten av august, og feilen står heller ikke i CISAs liste over kjent utnyttede sårbarheter. Det gir organisasjoner et vindu til å patche, men vinduet er ikke uendelig.
CloudNativePG: fra databaseeier til superbruker på ett trinn
CloudNativePG er en av de mest brukte Kubernetes-operatørene for PostgreSQL, vedlikeholdt av EDB (tidligere EnterpriseDB) og en åpen kildekode-fellesskap rundt prosjektet. CVE-2026-55769, med CVSS-score 9,4, er en privilegie-eskalering som lar en rolle med kun DATABASE OWNER-rettigheter ta seg helt opp til PostgreSQL-superbruker (OpenCVE).
Rotårsaken er teknisk, men konsekvensen er ikke det. Operatøren åpnet superbruker-tilkoblinger uten å låse søkestien («search_path») som brukes til å slå opp databaseobjekter. En databaseeier kunne dermed plante overbelastede, egendefinerte operatorer i public-skjemaet og manipulere søkestien slik at operatørens egne, priviligerte spørringer utilsiktet kalte den ondsinnede koden. Herfra er veien kort til å utføre operativsystem-kommandoer via COPY ... FROM PROGRAM, og videre til å lese servicekontoens token direkte fra poden, som igjen kan brukes til å bevege seg videre i klyngen.
CloudNativePG-teamet fikset problemet ved å pinne søkestien til pg_catalog, public, pg_temp på alle sammenkoblede tilkoblinger. Fiksen kom i versjon 1.30.0, som ble sluppet allerede 29. juni 2026, og ble portert bakover til 1.29.2 og 1.28.4 (CloudNativePG). CVE-nummeret ble først offentliggjort i midten av august, altså nesten to måneder etter at koderettelsen faktisk var tilgjengelig, noe som betyr at oppmerksomme driftsteam kan ha vært beskyttet lenge før sikkerhetsvarselet gikk ut. Det understreker hvor viktig det er å følge versjonsnotater, ikke bare CVE-databaser.
Prowler: sikkerhetsskanneren med den høyeste alvorlighetsgraden
Den mest ironiske av de fire sakene er trolig CVE-2026-73263, funnet i Prowler. Prowler beskriver seg selv som verdens mest brukte åpen kildekode-plattform for skysikkerhet, med over 45 millioner nedlastinger, mer enn 14 000 stjerner på GitHub og over 300 bidragsytere (Prowler). Det er nettopp verktøyet mange team bruker for å finne feilkonfigurasjoner og sårbarheter i egen skyinfrastruktur, inkludert i Kubernetes.
Feilen lå i selve tilkoblingstesten Prowler kjører når en bruker legger til en ny Kubernetes-tilkobling. En angriper kunne bygge en kubeconfig-fil som brukte den utdaterte GCP-autentiseringsmekanismen «auth-provider», komplett med et cmd-path– og cmd-args-felt. Når Prowlers API lastet inn denne konfigurasjonen for å teste tilkoblingen, utførte Kubernetes’ egen Python-klient kommandoen direkte via subprocess.Popen på en delt arbeidsprosess. Med en CVSS-score på 9,9 er dette den mest alvorlige av alle fire sakene, fordi den i praksis lar en autentisert bruker kjøre vilkårlig kode på en server som deles med andre kunder eller prosjekter.
Prowler rettet feilen i versjon 5.36.0, hvor den interne funksjonen som skulle sjekke for kommandobasert autentisering ble omdøpt og utvidet til å blokkere alle varianter av den utdaterte mekanismen (Open Source Drop). Ingen offentlig kilde melder om masseutnyttelse, men flere sikkerhetsanalytikere har påpekt at feilen er triviell å utnytte for enhver bruker som har lov til å legge inn en kubeconfig, noe som i mange organisasjoner er en lavere terskel enn man skulle tro.
Kubelet og SPDY: en eldre bibliotekfeil får ny oppmerksomhet
Den fjerde saken skiller seg fra de tre andre både i alvorlighetsgrad og opprinnelse. CVE-2026-35469 er en denial-of-service-sårbarhet i Go-biblioteket spdystream, som brukes av kubelet, CRI-O og kube-apiserver til å håndtere SPDY-strømming for funksjoner som kubectl exec, attach og port-forward. Frame-parseren validerer ikke lengder og antall felt før den allokerer minne, slik at en liten, komprimert header-blokk kan tvinge fram enorme minneallokeringer og gjøre komponenten utilgjengelig (Red Hat).
Sårbarheten i selve biblioteket ble opprinnelig avdekket i april 2026, men ble først formelt knyttet til Kubernetes’ offisielle CVE-liste i august, med CVSS-score 6,5, altså middels alvorlighetsgrad. Det krever nemlig at angriperen allerede har visse klyngerettigheter, som tilgang til port-forward, exec, attach eller nodes/proxy, noe som begrenser hvem som reelt kan utnytte den. SUSE fikset problemet ved å oppdatere til Kubernetes 1.33.11 i sin kubernetes-old-pakke (SUSE), mens Red Hat rettet den i OpenShift 4.21 gjennom sikkerhetsoppdateringen RHSA-2026:17475, datert 9. august. Selve spdystream-biblioteket er fikset i versjon 0.5.1.
Selv om denne saken har lavere CVSS-score enn de tre andre, illustrerer den et vanlig problem i containerøkosystemet: kode som er lånt inn fra et tredjeparts Go-bibliotek, og som ikke får samme oppmerksomhet som Kubernetes’ egen kjernekode, kan likevel ligge dypt begravd i kritiske komponenter som kubelet.
Ingress-NGINX: fem måneder senere, fortsatt upatchet i produksjon
De fire nye sakene kommer også oppå en sårbarhet som allerede var kjent: CVE-2026-4342 i Ingress-NGINX-kontrolleren, med CVSS 8,8. Den ble opprinnelig avslørt 19. mars 2026 og rettet i versjonene 1.13.9, 1.14.5 og 1.15.1. Likevel viser forskning fra sikkerhetsselskapet O3 Security at produksjonsklynger fortsatt kjører sårbare versjoner fem måneder etter at fiksen ble tilgjengelig. Det er ingen bekreftede tilfeller av aktiv utnyttelse så langt, men det lange etterslepet er talende for hvor treg patch-adopsjonen kan være selv for høyprofilerte Kubernetes-sårbarheter.
Settes de fem sakene sammen (Ingress-NGINX, MCE, CloudNativePG, Prowler og kubelet), tegner de et bilde av et økosystem der komponentene som binder klynger sammen, autentiserer dem, drifter dem og reviderer dem, alle har hatt kritiske svakheter innenfor det samme halvåret. Det er verdt å presisere: dette betyr ikke at Kubernetes som plattform er blitt mindre sikker. Det betyr at flere ledd i verktøykjeden rundt Kubernetes nå får den gjennomgangen de burde ha fått for lenge siden.
Sammenligning: alvorlighetsgrad og patch-status
Tabellen under oppsummerer de fem sakene som til sammen definerer «CVE-bølgen» i Kubernetes-verktøy sommeren og høsten 2026.
| CVE | Komponent | CVSS | Offentliggjort | Fikset i | Utnyttet i praksis? |
|---|---|---|---|---|---|
| CVE-2026-73263 | Prowler (Kubernetes-tilkobling) | 9,9 Kritisk | 12. aug. 2026 | 5.36.0 | Ingen bekreftet |
| CVE-2026-55769 | CloudNativePG (PostgreSQL-operatør) | 9,4 Kritisk | ~20. aug. 2026 | 1.28.4 / 1.29.2 / 1.30.0 | Ingen bekreftet |
| CVE-2026-66794 | Red Hat Multicluster Engine | 9,3 Kritisk | 19. aug. 2026 | Venter, mitigering tilgjengelig | Ingen bekreftet |
| CVE-2026-4342 | Ingress-NGINX-kontroller | 8,8 Høy | 19. mar. 2026 | 1.13.9 / 1.14.5 / 1.15.1 | Ingen bekreftet, men fortsatt upatchet mange steder |
| CVE-2026-35469 | Kubelet / CRI-O / kube-apiserver | 6,5 Middels | 19. aug. 2026 (K8s-liste) | spdystream 0.5.1 | Ingen bekreftet |
Mønsteret: når styringslaget selv blir angrepsflaten
Det som knytter disse sakene sammen er ikke bare timingen. Det er hva slags kode som ble rammet. Multicluster Engine, CloudNativePG og Prowler har alle én ting til felles: de kjører med utvidede rettigheter fordi jobben deres krever det. En klyngeforvalter må kunne nå flere klynger. En databaseoperatør må kunne administrere superbruker-tilkoblinger. Et sikkerhetsrevisjonsverktøy må kunne lese konfigurasjon på tvers av skytjenester. Denne kombinasjonen av bred tilgang og kompleks kode er nøyaktig den profilen angripere leter etter.
Det finnes også et strukturelt poeng her. Etter hvert som flere organisasjoner sentraliserer driften av titalls eller hundrevis av klynger i verktøy som RHACM, blir konsekvensen av én enkelt kompromittert komponent langt større enn før. I stedet for å angripe én applikasjon i én klynge, kan en angriper som får fotfeste i styringslaget i prinsippet bevege seg på tvers av hele flåten. Det er den samme logikken som gjør identitetsleverandører og sentrale CI/CD-systemer til attraktive mål: bredden i tilgang gjør dem verdifulle for angripere, selv når selve sårbarheten er teknisk sett «bare» en SSRF eller en manglende inputvalidering.
Konkurransebildet: Red Hat, CloudNativePG og Prowler i markedet
Alle tre kritiske sårbarheter rammer aktører med betydelig markedsposisjon, noe som forsterker rekkevidden av sakene. Ifølge analyseselskapet Omdia har Red Hat befestet sin posisjon som den ledende uavhengige programvareleverandøren (ISV) i markedet for kommersielt støttet containerforvaltning, og er samlet sett den tredje største aktøren i det bredere markedet for containerforvaltning og kjøretid, bak Amazon og Microsoft. Det plasserer RHACM og MCE som et de facto standardvalg for organisasjoner som administrerer OpenShift i stor skala, inkludert i offentlig sektor i Europa, der Red Hat lenge har hatt sterke posisjoner via partnere og systemintegratorer.
CloudNativePG konkurrerer med andre Kubernetes-native databaseoperatører, som Crunchy Data sin Postgres Operator og Zalando sin Patroni-baserte løsning, men har markert seg som et av de mest aktivt vedlikeholdte alternativene etter at prosjektet ble donert til CNCF. Prowler konkurrerer i sin tur med kommersielle skysikkerhetsplattformer som Wiz og Orca Security, samt med skyleverandørenes egne innebygde verktøy, som AWS Security Hub og Microsoft Defender for Cloud. Prowlers styrke har vært at det er gratis, åpen kildekode og dekker et bredt sett sjekker på tvers av AWS, Azure, GCP, Kubernetes og GitHub, noe som samtidig forklarer hvorfor en kritisk feil i nettopp dette verktøyet får så stor oppmerksomhet: det er installert i svært mange miljøer nettopp fordi det er gratis og enkelt å ta i bruk.
Historisk kontekst: fra Log4Shell til dagens forvaltningsverktøy-bølge
Mønsteret med sårbarheter i infrastrukturens støtteverktøy er ikke nytt. Log4Shell i desember 2021 viste hvor dypt et enkelt loggbibliotek kunne være begravd i tusenvis av applikasjoner uten at noen egentlig visste hvor det lå. XZ Utils-bakdøren i 2024 viste at selv grunnleggende Linux-verktøykjeder kan bli kompromittert gjennom sosial manipulasjon av vedlikeholdere. Det som skiller dagens Kubernetes-verktøybølge fra disse tidligere hendelsene, er at ingen av de fire nye CVE-ene ser ut til å stamme fra et bevisst angrep på leverandørkjeden. De er i stedet resultatet av systematisk, i flere tilfeller AI-assistert, sikkerhetsgranskning av kode som har eksistert i årevis uten grundig revisjon.
Det er også en videreføring av et mønster shattered.io har dekket gjennom 2026: en jevn strøm av kritiske Kubernetes-relaterte sårbarheter i containerd, i AKS-kontrollplanet og nå i forvaltningslaget rundt selve klyngene. Containerd-sårbarhetene som rammet EKS og GKE tidligere i år, og AKS-sårbarheten med CVSS 9,4, handlet begge om selve klyngens kjøretidsmiljø. Denne uken handler det i stedet om verktøyene rundt klyngen, som er et tegn på at sikkerhetsgranskningen nå brer seg utover kjernen og inn i det bredere økosystemet.
Konsekvenser for norske og nordiske skyoperatører
For norske og nordiske virksomheter som har bygget ut Kubernetes-drift de siste årene, ofte gjennom en kombinasjon av administrerte tjenester som AKS, EKS og GKE, samt egendriftede OpenShift-klynger i offentlig sektor og finans, er de fire sakene relevante av tre grunner. For det første er Red Hat OpenShift utbredt nettopp i regulerte sektorer, som bank og offentlig forvaltning, der flerklynge-forvaltning via RHACM og MCE er standard praksis for å holde styr på miljøer i test, produksjon og eventuelt separate soner for suverene skyløsninger. For det andre er PostgreSQL, og dermed CloudNativePG, et svært vanlig databasevalg i nordiske virksomheter som ønsker å unngå leverandørbinding til proprietære skydatabaser. For det tredje er Prowler, nettopp fordi det er gratis, et populært valg for mindre organisasjoner og konsulentmiljøer som ikke har budsjett til dyre kommersielle skysikkerhetsplattformer.
Praktisk betyr dette at driftsteam bør prioritere tre ting umiddelbart: kartlegge om organisasjonen kjører RHACM eller MCE med cluster-proxy-addon eksponert mot internett, sjekke CloudNativePG-versjonen mot 1.28.4/1.29.2/1.30.0-grensen, og oppgradere enhver Prowler-installasjon som tillater brukere å legge inn egne kubeconfig-filer til versjon 5.36.0 eller nyere.
Slik reduserer du risikoen: konkrete tiltak
Ingen av de fire sakene krever en fullstendig arkitekturendring for å håndtere på kort sikt. De krever derimot rask, presis oppfølging fra driftsteam som vet nøyaktig hvilke versjoner som kjører hvor. Tabellen under oppsummerer anbefalte tiltak per komponent.
| Komponent | Risikonivå | Umiddelbart tiltak | Tidsramme | Langsiktig tiltak |
|---|---|---|---|---|
| Red Hat MCE / RHACM | Kritisk | Begrens nettverkstilgang til cluster-proxy Route | Umiddelbart | Oppgrader når patch foreligger |
| CloudNativePG | Kritisk | Oppgrader til 1.28.4 / 1.29.2 / 1.30.0 | Denne uken | Aktiver automatisk versjonsvarsling |
| Prowler | Kritisk | Oppgrader til 5.36.0, begrens hvem som kan legge inn kubeconfig | Umiddelbart | Kjør skannearbeidere med minst mulig rettigheter |
| Ingress-NGINX | Høy | Verifiser versjon mot 1.13.9 / 1.14.5 / 1.15.1 | Denne uken | Vurder overgang til alternativ kontroller ved EOL |
| Kubelet / CRI-O | Middels | Begrens RBAC for exec/attach/port-forward/nodes-proxy | Denne måneden | Oppdater til spdystream 0.5.1 eller nyere plattformversjon |
Et gjennomgående råd fra alle fire leverandørene er å behandle nettverkstilgang til styringskomponenter som en egen sikkerhetssone, atskilt fra selve arbeidslasten. Det høres opplagt ut, men i praksis er det nettopp mangelen på denne atskillelsen som gjorde flere av sakene utnyttbare i utgangspunktet.
Markedspåvirkning: hva betyr dette for leverandørene?
Ingen av de tre leverandørene har foreløpig rapportert konkrete økonomiske konsekvenser av sakene, og det er for tidlig å måle eventuell kundeavgang. Men det er verdt å merke seg at alle tre har respondert raskt med patcher og offentlige rådgivninger, noe som historisk sett har vært den viktigste faktoren for hvordan markedet vurderer leverandørers håndtering av sikkerhetshendelser. Red Hat, som den klart største av de tre målt i omsetning og markedsandel, har mest å tape omdømmemessig gitt sin posisjon i regulerte bransjer. Prowler, som er avhengig av tillit fra sikkerhetsmiljøet for å opprettholde sin status som «mest brukte» åpen kildekode-verktøy, har et sterkere insentiv til rask og transparent oppfølging, og har allerede levert en fiks innen få uker fra oppdagelse.
For kjøpere kan sakene også skyve etterspørselen i retning av leverandører som kan dokumentere egne interne sikkerhetsrevisjonsprogrammer, slik Red Hats «Project Glasswing»-initiativ er et eksempel på. Å kunne vise til en systematisk, pågående gjennomgang av eldre kode kan i økende grad bli et konkurransefortrinn, ikke bare et sikkerhetstiltak.
Fem spådommer for resten av 2026
- Flere AI-assisterte kodegjennomganger avdekker flere «gamle» feil. Metoden som fant MCE-sårbarheten vil trolig bli brukt på flere modne Kubernetes-relaterte prosjekter i høst, noe som sannsynligvis gir flere CVE-er i komponenter som ikke har vært revidert på flere år.
- Flerklynge-forvaltning får strengere nettverkssegmentering som standard. Leverandører av verktøy som RHACM vil trolig anbefale, eller på sikt kreve, at proxy-komponenter som cluster-proxy-addon aldri eksponeres direkte mot internett.
- Databaseoperatører for Kubernetes får hardere skille mellom rettighetsnivåer. Etter CloudNativePG-saken er det sannsynlig at konkurrerende operatører gjennomgår egen håndtering av superbruker-tilkoblinger og søkestier proaktivt, før de blir tvunget til det av en egen CVE.
- Sikkerhetsverktøy blir selv gjenstand for strengere leverandørvurdering (tredjepartsrisiko). Organisasjoner som kjøper eller tar i bruk skannere og revisjonsverktøy vil i økende grad kreve dokumentasjon på hvordan verktøyet selv håndterer brukerinnsendt konfigurasjon, spesielt kubeconfig-filer og skyautentisering.
- Ingress-NGINX sin trege patch-adopsjon blir et gjentakende tema. Med prosjektet på vei mot end-of-life vil det trolig komme flere rapporter om upatchede produksjonsklynger utover høsten, noe som kan akselerere migrering til alternative ingress-kontrollere.
Vanlige spørsmål om CVE-bølgen i Kubernetes-verktøy
Er min Kubernetes-klynge direkte sårbar for disse fire CVE-ene?
Ikke nødvendigvis. Alle fire sakene krever at organisasjonen faktisk kjører den spesifikke komponenten: Red Hat Multicluster Engine eller RHACM, CloudNativePG, Prowler med Kubernetes-tilkobling aktivert, eller en Kubernetes-distribusjon med en upatchet spdystream-versjon. Sjekk versjonsnumrene mot tabellene over for å avgjøre eksponering.
Hvilken av de fire sårbarhetene bør jeg prioritere først?
Prowler-saken (CVE-2026-73263) har høyest CVSS-score på 9,9 og er beskrevet som triviell å utnytte for en autentisert bruker, så den bør normalt patches først dersom du kjører Prowler med brukerinnsendte kubeconfig-filer. Deretter følger CloudNativePG (9,4) og Red Hat MCE (9,3), som begge er kritiske, men krever noe mer spesifikke forutsetninger for å utnyttes.
Er noen av sårbarhetene bekreftet utnyttet i praksis?
Nei. Ingen av de fire nye CVE-ene, eller den eldre Ingress-NGINX-saken, er per slutten av august 2026 bekreftet utnyttet i faktiske angrep, og ingen står oppført i CISAs liste over kjent utnyttede sårbarheter. Det kan endre seg raskt, spesielt for Prowler-saken gitt hvor enkel den er å utnytte.
Hva er forskjellen på denne bølgen og tidligere Kubernetes-CVE-er som containerd- og AKS-sakene?
De tidligere sakene, som containerd-sårbarhetene og AKS-kontrollplan-feilen, rammet selve kjøretidsmiljøet klyngen kjører på. Denne bølgen rammer i stedet verktøyene rundt klyngen: forvaltning på tvers av flere klynger, databaseoperatører og sikkerhetsrevisjon. Angrepsflaten er annerledes, men konsekvensen, potensiell tap av kontroll over klyngen, kan være like alvorlig.
Må jeg slutte å bruke Prowler eller CloudNativePG etter dette?
Nei. Begge prosjektene har levert raske, veldokumenterte rettelser, og det er ingen tegn til at hendelsene svekker prosjektenes langsiktige levedyktighet. Rådet er å oppgradere til de fikserte versjonene, ikke å bytte verktøy.
Hvordan finner jeg ut om organisasjonen min bruker en av de sårbare komponentene?
Start med en oversikt over hvilke Kubernetes-operatører og forvaltningsverktøy som er installert i klyngene deres, for eksempel via kubectl get deployments -A kombinert med en gjennomgang av Helm-utgivelser. For Prowler og CloudNativePG holder det å sjekke versjonstagg på container-imaget. For Red Hat MCE/RHACM må du i tillegg kartlegge om cluster-proxy-addon sin Route er eksponert mot eksterne nettverk.
Påvirker dette skytjenester som AKS, EKS og GKE direkte?
Kubelet-sårbarheten (CVE-2026-35469) påvirker i prinsippet enhver Kubernetes-distribusjon som bruker en upatchet versjon av spdystream, inkludert administrerte tjenester, men skyleverandørene har egne oppdateringssykluser og patcher normalt kontrollplanet på vegne av kunden. De tre andre sakene er knyttet til spesifikke tredjepartsverktøy (Red Hat MCE, CloudNativePG, Prowler) og påvirker AKS, EKS og GKE kun dersom disse verktøyene er installert oppå de administrerte klyngene.
Related Coverage
- Azure AKS-Sårbarhet: CVSS 9,4, 415 Feil Patchet [2026]
- Containerd-sårbarheter: CVSS 8,8 rammer EKS og GKE [2026]
- Kubernetes 1.36: EKS-Støtte fra Juni, 26 Måneder Levetid [2026]
- Kubernetes Container-sikkerhet: 12 Steg, 45 Min [2026]
- Kubernetes In-Place Pod Resize: 12 Steg, 45 Min [2026]
Se flere saker i kategorien Skytjenester for løpende dekning av Kubernetes-, AWS-, Azure- og GCP-relaterte sikkerhetshendelser.
