CVE-2026-70398: Kritisk fejl i Red Hat ACM GitOpsCluster
Fejl i Red Hat Advanced Cluster Management lader en tenant stjæle andre klyngers adgangstokens. Opdatér multicloud-integrations nu.
Hvad er det?
Sårbarheden findes i multicloud-integrations, en del af Red Hat Advanced Cluster Management (RHACM), et værktøj til at styre flere Kubernetes-klynger fra ét sted. Fejlen sidder i GitOpsCluster-controlleren, som styrer forbindelsen til de såkaldte spoke-klynger, altså de underliggende klynger der administreres centralt. En bruger med begrænsede rettigheder, en tenant, kan manipulere controlleren til at sende følsomme bearer-tokens, som er adgangsnøgler til andre klynger, videre til et navnerum tenanten selv kontrollerer. Det giver adgang til oplysninger og systemer, brugeren normalt ikke må se, og omgår de sikkerhedsgrænser ArgoCD AppProjects er sat til at håndhæve.
Hvem rammer det?
Det rammer organisationer der bruger Red Hat Advanced Cluster Management til at styre flere Kubernetes-klynger, og som har flere tenants eller afdelinger med adgang til samme RHACM-installation via GitOps-integration med ArgoCD. Det gælder typisk kommuner, større virksomheder og it-driftsleverandører med intern eller ekstern multitenant Kubernetes-drift. Er I en almindelig virksomhed uden Kubernetes-platform eller RHACM, er I ikke berørt.
Hvad kan ske?
En bruger med lav adgang i systemet kan uden brugerinteraktion fra andre få fat i adgangstokens til andre klyngers ressourcer. I praksis betyder det, at en afdeling eller kunde med begrænset adgang kan læse og ændre data i en klynge, de ikke burde have adgang til. Det kan sprede sig til lateral bevægelse mellem klynger og give adgang til fortrolige data, konfigurationer eller hemmeligheder i andre dele af organisationen.
Hvor alvorligt er det?
CVSS-scoren er 9,6 ud af 10, hvilket er kritisk. Angrebet kræver kun lav adgang i systemet i forvejen, PR:L, ingen brugerinteraktion fra andre, og kan udføres over netværket. Konsekvensen er høj for fortrolighed og integritet, mens tilgængeligheden ikke påvirkes. Der er ikke oplysninger om, at sårbarheden aktivt udnyttes, men den lave adgangsbarriere gør den attraktiv for en ondsindet intern bruger eller kunde i et multitenant-miljø.
Hvad gør jeg nu?
Prioritér disse skridt, hvis I kører Red Hat Advanced Cluster Management:
- Opdatér multicloud-integrations-komponenten til den rettede version via Red Hats sikkerhedsopdateringer, det lukker selve hullet.
- Gennemgå hvilke tenants der har adgang til GitOpsCluster-ressourcer, og begræns rettigheder til det strengt nødvendige.
- Roter bearer-tokens for alle spoke-klynger, så eventuelt allerede eksponerede tokens bliver ugyldige.
- Gennemgå ArgoCD AppProject-konfigurationer for at sikre, at namespace-grænser mellem tenants håndhæves korrekt.
- Tjek logs for uventet oprettelse af secrets eller GitOpsCluster-objekter i uvante navnerum.
- Kontakt jeres it-leverandør eller Auroa, hvis I ikke selv har ressourcer til at vurdere RBAC-opsætningen i RHACM.
Opdatér inden for få dage
Vi anbefaler, at I opdaterer multicloud-integrations-komponenten i RHACM snarest og samtidig strammer op på, hvilke rettigheder tenants har til GitOpsCluster-ressourcer. Det er kun forsvarligt at vente, hvis jeres RHACM-installation ikke bruges af flere adskilte tenants eller kunder. Har I en fælles klyngeplatform for flere afdelinger eller kunder, bør opdateringen have topprioritet.
Tidslinje
Konkrete eksempler
Delt Kubernetes-platform i en kommune
En kommune driver en fælles RHACM-platform, hvor forskellige forvaltninger fungerer som separate tenants med adgang til hver deres spoke-klynge. En medarbejder i én forvaltning med almindelig, lav adgang udnytter fejlen i GitOpsCluster-controlleren til at omdirigere en anden forvaltnings bearer-token til sit eget navnerum. Dermed får vedkommende adgang til data og systemer i en klynge, forvaltningen ikke har rettigheder til.
Ofte stillede spørgsmål
Hvordan finder vi ud af, om vi bruger den ramte komponent?
Tjek om jeres Kubernetes-drift bruger Red Hat Advanced Cluster Management, og om multicloud-integrations-operatoren er installeret sammen med GitOpsCluster-integration til ArgoCD. Er I i tvivl, kan jeres platformteam eller leverandør bekræfte det.
Kan vi vente til den planlagte vedligeholdelsesweekend?
Hvis I har flere tenants med adgang til samme RHACM-installation, bør I ikke vente. Angrebet kræver kun lav adgang og ingen handling fra andre, så risikoen løber videre, indtil opdateringen er på plads.
Skal vi anmelde noget til Datatilsynet, hvis vi er ramt?
Kun hvis I finder tegn på, at tokens faktisk er blevet misbrugt til at tilgå personoplysninger. Uden konkrete tegn på udnyttelse er der ikke pligt til anmeldelse, men vi anbefaler at logge og undersøge sagen grundigt først.
Er sårbarheden udnyttet i praksis?
Der er ingen offentlige oplysninger om aktiv udnyttelse på offentliggørelsestidspunktet. Det ændrer ikke ved, at fejlen bør rettes, da adgangsbarrieren for et angreb er lav.
Påvirker det vores eksterne kunder, hvis vi driver en delt Kubernetes-platform?
Ja. Hvis jeres kunder har hver deres tenant i samme RHACM-installation, kan én kunde i teori få adgang til en anden kundes spoke-klynge. Det gør opdateringen særligt vigtig for it-driftsleverandører.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
A flaw was found in multicloud-integrations, a component of Red Hat Advanced Cluster Management (RHACM). This vulnerability allows an authenticated user, referred to as a tenant, to manipulate the GitOpsCluster controller. By exploiting this, a tenant can redirect sensitive spoke cluster bearer tokens from secure locations to a namespace they control. This unauthorized access to tokens can lead to the disclosure of critical information and bypass security policies within ArgoCD AppProjects.
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.