CVE-2026-72526: Kritisk fejl i multicloud-integrations & ArgoCD

CVE-2026-72526 er en sårbarhed i komponenten multicloud-integrations, som styrer, hvordan applikationer fordeles fra en central hub-klynge til underliggende spoke-klynger i et Kubernetes-miljø. Fejlen ligger i, at systemet stoler blindt på en annotation (en mærkat på en teknisk ressource) kaldet ocm-managed-cluster uden at tjekke, om afsenderen faktisk har ret til at pege på den pågældende klynge. En bruger, der blot har lov til at oprette Applications på hub-klyngen, kan derfor pege på en helt anden klynge og tvinge ArgoCD, det værktøj der synkroniserer konfiguration, til at hente og køre indhold, angriberen selv har bestemt. Det kaldes et ‘confused deputy’-problem: systemet handler på vegne af nogen, det ikke burde stole på.

Sårbarheden rammer organisationer, der driver flere Kubernetes-klynger samlet via multicloud-integrations sammen med ArgoCD, typisk i opsætninger med en central hub-klynge og flere spoke-klynger. Det gælder blandt andet kommuner og større virksomheder, der bruger Red Hat Advanced Cluster Management eller lignende multiklynge-styring til drift af flere afdelinger, systemer eller kunder på samme platform. Er I kun på én enkelt Kubernetes-klynge uden hub/spoke-opsætning, er I ikke berørt af netop denne fejl.

En intern bruger eller en angriber, der har fået begrænset adgang til hub-klyngen, kan udnytte fejlen til at tvinge en helt anden, styret klynge til at synkronisere manifester (konfigurationsfiler), som angriberen selv har lavet. Det kan give kørsel af vilkårlig kode på den ramte klynge og dermed adgang til data, systemer og eventuelt andre kunders eller afdelingers miljøer, hvis klyngerne deler infrastruktur. For en dansk organisation betyder det i praksis, at en enkelt kompromitteret konto med begrænsede rettigheder kan eskalere til fuld kontrol over flere driftsmiljøer.

CVSS-scoren er 9,9 ud af 10, kritisk. Angrebet kræver kun netværksadgang og lave rettigheder (mulighed for at oprette en Application på hub-klyngen), ingen brugerinteraktion er nødvendig, og angrebskompleksiteten er lav. Konsekvensen rammer fortrolighed, integritet og tilgængelighed fuldt ud, og fejlen kan påvirke systemer ud over den, angriberen oprindeligt har adgang til, hvilket forklarer den høje score. Der er ikke rapporteret aktiv udnyttelse på offentliggørelsestidspunktet, men fejlen kræver ikke avancerede angrebsteknikker.

Prioritér disse skridt, hvis I bruger multicloud-integrations med ArgoCD i en hub/spoke-opsætning:

1. Opdatér multicloud-integrations til den version, hvor validering af ocm-managed-cluster-annotationen er indført, så snart leverandøren udgiver den.
2. Gennemgå, hvem der har rettighed til at oprette Applications på hub-klyngen, og begræns adgangen til det strengt nødvendige.
3. Indfør politik-kontrol (fx admission-kontroller), der validerer annotationsværdier, indtil den officielle rettelse er på plads.
4. Gennemgå logs for ArgoCD-synkroniseringer på spoke-klyngerne for uventede manifester fra ukendte kilder.
5. Isolér hub- og spoke-klynger netværksmæssigt, så en kompromitteret spoke-klynge ikke automatisk giver adgang videre.
6. Kontakt jeres sikkerhedsleverandør eller Auroa, hvis I ikke selv har overblik over jeres hub/spoke-opsætning eller mangler ressourcer til at gennemgå rettigheder og logs.