CVE-2026-22872: Kritisk fejl i Capsule til Kubernetes

Capsule er et framework til multi-tenancy i Kubernetes, det vil sige et værktøj der lader flere afdelinger, kunder eller projekter dele samme Kubernetes-klynge uden at kunne se eller påvirke hinandens ressourcer. Capsule Controller, den komponent der styrer adgangsstyringen, kører selv med cluster-admin rettigheder, altså fuld adgang til hele klyngen. CVE-2026-22872 betyder, at en administrator for en enkelt tenant (afdeling eller kunde) kan udnytte Controllerens rettigheder til at oprette ressourcer, der gælder for hele klyngen, som ClusterRole og ValidatingWebhookConfiguration, selv om vedkommende ikke må oprette dem direkte. Det bryder isolationen mellem tenants og kan give kontrol over hele klyngen.

Rammer alle, der kører Capsule i version ældre end 0.13.0 til at dele en Kubernetes-klynge mellem flere tenants. Det gælder typisk hostingudbydere, offentlige it-fællesskaber og virksomheder, der stiller udviklingsmiljøer til rådighed for flere afdelinger eller kunder på samme klynge. Sårbarheden kræver, at angriberen allerede har rollen Tenant Owner i mindst én tenant, det er altså ikke en helt ekstern angriber uden adgang.

En bruger med begrænset adgang til sin egen tenant kan skabe klynge-dækkende ressourcer og dermed opnå kontrol, der normalt kun tilfalder klyngens administrator. I praksis kan personen læse eller ændre andre tenants’ data, oprette en skadelig ValidatingWebhookConfiguration der opsnapper eller blokerer trafik i hele klyngen, eller give sig selv rettigheder svarende til hele Kubernetes-miljøet. For en virksomhed, der stiller delt infrastruktur til rådighed for kunder eller afdelinger, betyder det, at en enkelt kompromitteret tenant kan blive springbræt til alle øvrige.

CVSS-score er 9,1 ud af 10, kritisk. Angrebet kræver netværksadgang og lav teknisk kompleksitet, men kræver høje rettigheder i forvejen, nemlig rollen Tenant Owner, og ingen brugerinteraktion fra andre. Der er ikke krav om at nogen klikker på noget eller åbner en fil. Der er ikke rapporteret aktiv udnyttelse eller offentligt tilgængelig kode til at udnytte fejlen på offentliggørelsesdatoen, men fordi svagheden bryder selve formålet med multi-tenancy, altså isolationen mellem kunder eller afdelinger, vurderer vi konsekvensen som meget høj, hvis den udnyttes.

Følgende trin lukker hullet og begrænser risikoen, mens I opgraderer:

1. Opgradér Capsule til version 0.13.0 eller nyere. Det er den officielle løsning, der lukker sårbarheden.
2. Gennemgå, hvem der har rollen Tenant Owner i jeres klynge, og fjern rollen fra brugere, der ikke har brug for den.
3. Undersøg jeres klynge for uventede ClusterRole- og ValidatingWebhookConfiguration-objekter, der kan være oprettet af tenant-administratorer forud for opgraderingen.
4. Slå audit-logning til for oprettelse af klynge-dækkende ressourcer, så I fremover kan opdage forsøg på misbrug.
5. Overvej at indføre en admission controller, der yderligere begrænser tenants’ mulighed for at oprette klynge-dækkende objekter, som et ekstra lag beskyttelse.
6. Kontakt Auroa eller en anden sikkerhedsrådgiver, hvis I driver en delt Kubernetes-platform for flere kunder eller afdelinger og er i tvivl om, hvordan opgraderingen påvirker jeres opsætning.