CVE-2026-67567: Kritisk rettighedsfejl i Kubernetes HelmRelease
Alvorlig rettighedsfejl i multicloud-operators-subscription lader en bruger med adgang til HelmRelease overtage hele Kubernetes-klyngen. Begræns adgangen nu.
Hvad er det?
CVE-2026-67567 er en fejl i komponenten multicloud-operators-subscription, som bruges til at styre Helm-baserede applikationer i Kubernetes-klynger, blandt andet i Red Hat Advanced Cluster Management. Fejlen er en såkaldt confused deputy-sårbarhed (CWE-441): systemets HelmRelease-controller behandler Helm-chart-skabeloner med sine egne høje rettigheder, uden at tjekke om den, der har bedt om det, må have de rettigheder. En bruger, der kun har lov til at oprette HelmRelease-ressourcer i eget område, kan derfor udnytte controllerens rettigheder til at oprette hvad som helst i hele klyngen.
Hvem rammer det?
Sårbarheden rammer organisationer, der bruger multicloud-operators-subscription til at styre Helm-applikationer på tværs af Kubernetes-klynger, typisk som del af Red Hat Advanced Cluster Management. Det gælder især miljøer med flere lejere (multi-tenant), hvor forskellige teams, afdelinger eller eksterne leverandører har adgang til at oprette HelmRelease-objekter i deres eget navnerum, men ikke skal kunne påvirke resten af klyngen. Det kan for eksempel være kommuner eller virksomheder, der driver en fælles container-platform for flere afdelinger eller kunder.
Hvad kan ske?
En bruger med begrænset adgang kan oprette en HelmRelease-ressource, der i praksis udnytter controllerens administratorrettigheder til at oprette vilkårlige ressourcer i hele klyngen. Det betyder, at brugeren kan tilgå andre afdelingers data, ændre eller slette systemkomponenter, oprette nye administratorkonti eller placere skadelig kode i klyngen. I en delt platform kan én afdeling med begrænset adgang dermed reelt overtage kontrollen med hele infrastrukturen.
Hvor alvorligt er det?
CVSS-scoren er 9,9 ud af 10, hvilket er kritisk. Angrebet kræver kun et lavt privilegeret login (adgang til at oprette en HelmRelease), ingen handling fra en anden bruger og kan gennemføres over netværket uden kompleks forberedelse. Konsekvensen rammer fortrolighed, integritet og tilgængelighed fuldt ud, fordi angrebet krydser sikkerhedsgrænsen (scope changed) og påvirker hele klyngen, ikke kun brugerens eget område. Der er ikke oplysninger om aktiv udnyttelse i praksis på offentliggørelsestidspunktet.
Hvad gør jeg nu?
Følgende skridt bør prioriteres, hvis I bruger multicloud-operators-subscription eller Red Hat Advanced Cluster Management:
- Opdatér multicloud-operators-subscription til den rettede version, så snart leverandøren udsender en opdatering. Følg Red Hats sikkerhedsbulletiner for præcis version.
- Gennemgå hvem der har rettigheder til at oprette HelmRelease-ressourcer, og fjern denne rettighed fra brugere og teams, der ikke har et konkret behov.
- Indfør en admission-politik (adgangskontrol-regel), der begrænser hvilke Helm-charts og namespaces en HelmRelease må pege på.
- Gennemgå logs for uventede HelmRelease-oprettelser eller ressourceændringer uden for forventede namespaces.
- Isolér multi-tenant-klynger yderligere med netværkspolitikker, indtil opdateringen er på plads.
- Kontakt Auroa eller jeres Kubernetes-leverandør, hvis I er usikre på om jeres opsætning er sårbar, eller hvis I ikke selv har ressourcer til at gennemgå rettighedsstyringen.
Begræns adgang og opdatér snarest
Vi anbefaler, at I straks gennemgår, hvem der har rettighed til at oprette HelmRelease-ressourcer i jeres Kubernetes-klynger, og strammer denne adgang, mens I venter på en officiel opdatering. Det er ikke forsvarligt at vente til en fast servicevindue, hvis I driver en delt platform med flere lejere, fordi fejlen kan udnyttes uden brugerinteraktion og med lave rettigheder. Er jeres klynge kun brugt af et enkelt, tillidsfuldt team uden adgang for eksterne, kan I med rimelighed vente på leverandørens opdatering, men bør stadig følge status tæt.
Tidslinje
Konkrete eksempler
Delt Kubernetes-platform i en dansk kommune
En kommune driver en fælles Kubernetes-platform, hvor flere afdelinger hver har eget namespace og adgang til at oprette HelmRelease-ressourcer for deres egne applikationer. En afdeling med begrænset adgang opretter en HelmRelease, der udnytter controllerens rettigheder til at oprette en ny administratorkonto i hele klyngen. Herfra får afdelingen adgang til andre afdelingers systemer og data, som de aldrig skulle have kunnet tilgå.
Ofte stillede spørgsmål
Hvordan finder vi ud af, om vi er ramt?
Tjek om I bruger multicloud-operators-subscription, typisk som del af Red Hat Advanced Cluster Management, og om nogen uden for jeres administratorer har rettighed til at oprette HelmRelease-ressourcer i klyngen. Er svaret ja til begge dele, er I potentielt ramt.
Kan vi vente til weekenden med at reagere?
Hvis flere teams eller eksterne parter kan oprette HelmRelease-objekter i jeres klynge, bør I stramme adgangen samme dag. Har I en lukket klynge med kun betroede administratorer, kan I vente på leverandørens opdatering, men bør holde øje med nye meldinger.
Hvad er en HelmRelease egentlig?
En HelmRelease er en beskrivelse af, hvordan en applikation skal installeres i Kubernetes via Helm, et pakkeværktøj til Kubernetes. Normalt bruges den til at automatisere udrulning af applikationer i et afgrænset område af klyngen.
Skal vi anmelde hændelsen til nogen?
Sårbarheden i sig selv skal ikke anmeldes, medmindre den er blevet udnyttet og har medført et sikkerhedsbrud med adgang til persondata. Er I i tvivl om et faktisk misbrug, bør I undersøge logs og eventuelt kontakte Datatilsynet efter jeres normale procedurer for databrud.
Er der en midlertidig løsning, mens vi venter på en opdatering?
Ja. Fjern eller begræns rettigheden til at oprette HelmRelease-ressourcer for alle, der ikke er klyngeadministratorer, og indfør en admission-politik, der begrænser hvilke charts og namespaces en HelmRelease kan påvirke.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
A flaw was found in the multicloud-operators-subscription component. This vulnerability allows a tenant, who has the ability to create HelmRelease custom resources (CRs), to bypass existing security controls. The system’s HelmRelease controller processes Helm chart templates using its own elevated ServiceAccount privileges without proper validation. This enables the tenant to deploy arbitrary resources across the entire cluster, leading to a significant security compromise.
Referencer & kilder
Eksterne kilder
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.