CVE-2026-22872: Kritisk fejl i Capsule Kubernetes
Kritisk fejl i Kubernetes-værktøjet Capsule lader lejere oprette ressourcer med admin-rettigheder og overtage hele klyngen.
Hvad er det?
Capsule er et open source-værktøj til Kubernetes (et system til at køre og styre containerbaserede applikationer). Capsule gør det muligt at dele én Kubernetes-klynge op i isolerede ‘lejemål’ (tenants), så forskellige teams eller kunder ikke kan se eller påvirke hinanden. En fejl i versioner før 0.13.0 betyder, at en bruger med lejerejer-rettigheder (Tenant Owner) kan misbruge Capsule-controllerens administrative adgang til at oprette ressourcer på klyngeniveau — ressourcer vedkommende normalt slet ikke har lov at røre. Det er en klassisk privilege escalation-fejl: man starter med begrænsede rettigheder og slutter med fuld kontrol.
Hvem rammer det?
Fejlen rammer virksomheder og teams der:
- Kører Kubernetes og bruger Capsule til at opdele klyngen i lejemål (multi-tenancy)
- Har Capsule-versioner ældre end 0.13.0 installeret
- Tillader eksterne brugere, kunder eller separate interne teams at agere som lejerejer (Tenant Owner) i klyngen
Bruger du ikke Capsule, er du ikke berørt. Er du i tvivl, kan din driftsleverandør eller cloud-udbyder bekræfte om Capsule indgår i jeres opsætning.
Hvad kan ske?
En angriber med lejerejer-rettigheder kan udnytte fejlen til at:
- Oprette ClusterRoles (klyngeomfattende adgangsroller) og tildele sig selv eller andre fulde administratorrettigheder
- Opsætte ValidatingWebhookConfigurations — skjulte kroghændelser der kan aflytte eller manipulere al trafik i klyngen
- Bryde ud af sin isolerede lejer-boks og tilgå andre lejeres data og systemer
- Overtage hele Kubernetes-klyngen og de applikationer og data der kører der
Konsekvensen kan være fuldt datatyveri, sabotage af drift eller brug af klyngen som springbræt til videre angreb.
Hvor alvorligt er det?
CVSS-scoren er 9.1 ud af 10 (Kritisk). Angrebet kræver ingen brugerinteraktion og har lav angrebskompleksitet — når angriberen har lejerejer-adgang, er fremgangsmåden ligetil. Påvirkningen på fortrolighed, integritet og tilgængelighed er alle vurderet til Høj, og skaden rækker ud over angriberens eget lejemål til hele klyngen (scope changed). Den eneste dæmpende faktor er, at angriberen allerede skal have lejerejer-rettigheder — det kræver altså en intern bruger, kompromitteret konto eller en ekstern kunde med den adgang.
Hvad gør jeg nu?
Opdater Capsule hurtigst muligt. Følg disse trin:
- Kortlæg din version: Bed din drifts- eller cloud-leverandør om at tjekke hvilken version af Capsule der kører i jeres Kubernetes-klynge.
- Opdater til version 0.13.0 eller nyere: Rettelsen er tilgængelig. Planlæg opdateringen i en vedligeholdelsesvindueperiode for at minimere nedetid.
- Gennemgå lejerejer-konti: Tjek hvem der har Tenant Owner-rettigheder. Fjern adgang for brugere der ikke længere har behov.
- Aktiver ekstra adgangskontrol: Overvej om I kan tilføje yderligere admission controllers (adgangskontrolmekanismer) der kan blokere uønskede ressourceoprettelser.
- Overvåg logfiler: Gennemgå Kubernetes-auditlogfiler for usædvanlige oprettelser af ClusterRole eller ValidatingWebhookConfiguration de seneste måneder.
Opdater inden for 7 dage
Vi anbefaler at opdatere Capsule til version 0.13.0 hurtigst muligt — inden for én uge. Selvom angrebet kræver lejerejer-rettigheder, er det præcis den adgang eksterne kunder eller interne udviklere typisk har i en multi-tenant opsætning. Kombinationen af fuld klynge-overtagelse og den lave angrebskompleksitet gør denne sårbarhed til en reel og alvorlig trussel. Har I ikke ressourcerne internt, så kontakt jeres leverandør eller Auroa for hjælp til opdatering og gennemgang.
Tidslinje
Konkrete eksempler
Ekstern kunde opretter skjult admin-rolle
Et SaaS-selskab bruger Capsule til at give kunder deres eget isolerede lejemål i en delt Kubernetes-klynge. En kunde med lejerejer-adgang udnytter fejlen til at oprette en ClusterRole med fuld administratoradgang og binder den til sin egen bruger. Kunden har nu uindskrænket adgang til alle andre kunders data og applikationer i klyngen — uden at operatøren opdager det.
Angriber installerer skjult overvågningskrog
En angriber med kompromitteret lejerejer-konto opretter en ValidatingWebhookConfiguration der registrerer al API-trafik i klyngen og sender den til en ekstern server. Alle API-kald — inklusive dem med hemmeligheder og adgangsnøgler — bliver nu logget af angriberen. Angrebet er svært at opdage uden løbende auditloggennemgang.
Intern bruger eskalerer rettigheder til fuld klynge-admin
En udvikler hos en virksomhed har lejerejer-rettigheder til sit teams Kubernetes-lejemål, men ikke adgang til produktionsmiljøet. Via CVE-2026-22872 opretter udvikleren en ClusterRoleBinding der giver dennes bruger cluster-admin-rettigheder. Udvikleren kan nu tilgå, ændre og slette ressourcer i produktionsmiljøet, herunder databaser og hemmeligheder.
Ofte stillede spørgsmål
Bruger vi overhovedet Capsule?
Capsule installeres eksplicit i Kubernetes og er ikke en del af standard Kubernetes. Spørg jeres drifts- eller cloud-leverandør, eller bed dem køre kommandoen
kubectl get pods -A | grep capsulefor at tjekke. Bruger I ikke Capsule, er I ikke berørt af denne sårbarhed.Skal vi bekymre os, hvis kun interne medarbejdere er lejerejer?
Risikoen er lavere, men ikke elimineret. En kompromitteret medarbejderkonto kan give en ekstern angriber lejerejer-adgang. Angrebet kan også udføres af en intern bruger med ondsindede hensigter. Vi anbefaler stadig at opdatere og gennemgå hvem der har lejerejer-rettigheder.
Hvad er en ClusterRole, og hvorfor er det farligt?
En ClusterRole er en adgangsrolle der gælder for hele Kubernetes-klyngen — ikke kun ét afgrænset område. Kan en angriber oprette en ClusterRole og tildele den til sig selv, kan vedkommende få administratorrettigheder over alle applikationer, data og systemer i klyngen. Det svarer til at skaffe sig nøglen til hele bygningen i stedet for bare sin egen lejlighed.
Er der tegn på at sårbarheden allerede er udnyttet?
Der er ikke bekræftede rapporter om aktive angreb i stor skala på nuværende tidspunkt. Fejlen er dog offentligt beskrevet, og teknisk kyndige angribere kan udnytte den. Det er derfor vigtigt at handle hurtigt frem for at afvente.
Hvad hvis vi ikke kan opdatere med det samme?
Som midlertidig foranstaltning bør I gennemgå og begrænse hvem der har lejerejer-rettigheder til et absolut minimum. Overvej også at aktivere ekstra admission controllers i klyngen der kan begrænse oprettelsen af ClusterRoles og WebhookConfigurations. Disse tiltag reducerer risikoen, men erstatter ikke en opdatering.
Gælder dette alle cloud-udbydere?
Ja, sårbarheden er i Capsule-softwaren selv og er uafhængig af hvilken cloud-udbyder eller infrastruktur I bruger. Kører I Capsule hos AWS, Azure, Google Cloud eller on-premise, er I potentielt berørt hvis versionen er ældre end 0.13.0.
Ramte produkter
Projectcapsule — Capsule
< 0.13.0
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
Capsule is a multi-tenancy and policy-based framework for Kubernetes. The Capsule Controller runs with cluster-admin privileges. Although the TenantResource RawItems processing logic forcibly sets the namespace, this is ineffective for cluster-scoped resources. Prior to version 0.13.0, tenant administrators can leverage the Controller’s elevated privileges to create cluster-scoped resources (such as ClusterRole and ValidatingWebhookConfiguration) that they cannot create directly, achieving cross-tenant privilege escalation and cluster-level attacks. The attack vector has a few limiting factors. This attack requires Tenant Owner privileges and requires Capsule Controller running with cluster-admin privileges (default configuration). Additionally, some clusters may have additional admission controllers blocking malicious resources. Version 0.13.0 patches this issue.
Referencer & kilder
Officielle advisories
Eksterne kilder
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.