CVE-2026-71470: Kritisk fejl i search-v2-operator
En sårbarhed i search-v2-operator lader en bruger med redigeringsret til Search-ressourcer overtage hele Kubernetes-klyngen. Følg vendors sikkerhedsråd.
Hvad er det?
CVE-2026-71470 er en fejl i search-v2-operator, en styringskomponent (operator) der administrerer søgefunktionen i Kubernetes- og OpenShift-klynger, typisk som del af Red Hat Advanced Cluster Management. Fejlen hører til CWE-913, som betyder at operatoren ikke kontrollerer godt nok, hvilke ressourcer og kode der kan ændres dynamisk under drift. En bruger, der har ret til at redigere en Custom Resource, det vil sige en Kubernetes-objekttype defineret af operatoren, kan ændre felter som imageOverride, arguments og miljøvariabler uden validering. Det gør det muligt at bytte søgecontainerens image ud med et angriberkontrolleret image eller montere hemmeligheder ind i containeren, som brugeren ellers ikke har adgang til.
Hvem rammer det?
Sårbarheden rammer Kubernetes- og OpenShift-klynger, der har search-v2-operator installeret, blandt andet i forbindelse med Red Hat Advanced Cluster Management. Det er relevant for danske virksomheder og kommuner, der driver egne containerplatforme eller bruger en administreret klyngeløsning med denne operator, særligt hvis flere teams eller afdelinger har delt adgang til klyngen med rettigheder til at redigere Custom Resources.
Hvad kan ske?
En bruger, der allerede har redigeringsret til Search-relaterede ressourcer, kan udnytte fejlen til at få egen kode kørt med de rettigheder, som søgecontainerens ServiceAccount har. Da denne konto har omfattende impersonation-rettigheder, det vil sige mulighed for at udgive sig for andre brugere og konti i klyngen, kan angriberen i praksis opnå fuld kontrol over hele klyngen. Det rækker fra at læse alle hemmeligheder og konfigurationer til at ændre eller slette arbejdsbelastninger i produktionsmiljøet.
Hvor alvorligt er det?
CVSS-scoren er 9,1 ud af 10, kritisk. Angrebet kræver høje privilegier i forvejen (PR:H), altså at brugeren allerede har adgang til at redigere Search-ressourcer i klyngen. Der kræves ingen handling fra andre brugere (UI:N), og angrebet kan udføres over netværket med lav kompleksitet. Konsekvensen strækker sig ud over den sårbare komponent selv (scope changed), fordi den opnåede adgang kan bruges til at kompromittere resten af klyngen. Der er ved offentliggørelsen ikke oplysninger om aktiv udnyttelse i praksis.
Hvad gør jeg nu?
Følg disse trin for at reducere risikoen, mens I afventer en officiel opdatering:
- Undersøg om jeres klynger kører search-v2-operator, og opdatér til den version, hvor leverandøren har lukket fejlen, så snart den er tilgængelig.
- Gennemgå og begræns, hvem der har rettigheder til at redigere Search Custom Resources. Jo færre brugere med denne adgang, jo mindre er angrebsfladen.
- Tjek ServiceAccountens rettigheder for søgecontaineren, og fjern unødvendige impersonation-rettigheder, hvis det er muligt uden at bryde funktionaliteten.
- Overvåg logs for uventede ændringer i Search Custom Resources, især felterne imageOverride, arguments og miljøvariabler.
- Isoler klyngens administrative adgang med multifaktorgodkendelse og separate roller, så en enkelt kompromitteret konto ikke giver fuld klyngeadgang.
- Kontakt en sikkerhedsrådgiver eller jeres platformsleverandør, hvis I ikke selv kan verificere, om klyngen er ramt, eller hvis I skal have hjælp til at gennemgå rettighedsstrukturen.
Gennemgå adgangsrettigheder inden for en uge
Vi anbefaler, at I straks kortlægger, hvem i organisationen har redigeringsret til Search Custom Resources i jeres klynger, og strammer op på den adgang uanset opdateringsstatus. Det er i orden at afvente den officielle rettelse et par dage, hvis I i mellemtiden har begrænset antallet af privilegerede brugere og overvåger for ændringer i de nævnte felter. Har I mange brugere med delt administrativ adgang til klyngen, bør I prioritere gennemgangen højt, da konsekvensen ved udnyttelse er fuld klyngekompromittering.
Tidslinje
Konkrete eksempler
Delt klyngeadgang i en dansk kommunes IT-drift
En kommunes IT-afdeling driver en fælles Kubernetes-klynge, hvor flere teams har fået redigeringsret til Search-ressourcer for at kunne fejlsøge i søgefunktionen. En medarbejder med denne adgang, eller en person der har overtaget kontoen, ændrer imageOverride-feltet, så søgecontaineren i stedet kører et ondsindet image. Fordi containerens ServiceAccount har brede impersonation-rettigheder, kan angriberen herefter udgive sig for andre konti og få adgang til hemmeligheder og arbejdsbelastninger i hele klyngen, inklusive systemer, der håndterer borgerdata.
Ofte stillede spørgsmål
Er vi ramt af denne sårbarhed?
I er kun berørt, hvis jeres Kubernetes- eller OpenShift-klynge kører search-v2-operator, typisk som del af Red Hat Advanced Cluster Management. Tjek jeres klyngeinventar eller spørg jeres platformsleverandør, om operatoren er installeret.
Kræver angrebet, at nogen klikker på noget?
Nej. Der kræves ingen brugerinteraktion. Angriberen skal dog allerede have redigeringsret til Search-relaterede ressourcer i klyngen, hvilket normalt kun gives til betroede administratorer eller teams.
Kan vi vente til weekenden med at kigge på det?
Ja, hvis I i mellemtiden begrænser antallet af brugere med redigeringsret til Search Custom Resources og ikke ser tegn på uautoriserede ændringer. Er adgangen bredt uddelt i jeres organisation, bør I gennemgå det før weekenden.
Hvordan tjekker vi, om nogen har udnyttet fejlen?
Gennemgå logs for ændringer i Search Custom Resources, særligt felterne imageOverride, arguments og miljøvariabler. Uventede ændringer i disse felter eller ukendte container-images er tegn på misbrug.
Skal vi anmelde dette til myndighederne?
Kun hvis I konstaterer, at fejlen faktisk er blevet udnyttet, og persondata eller andre beskyttede oplysninger er blevet kompromitteret. Er der intet tegn på udnyttelse, er der ikke krav om anmeldelse alene på baggrund af sårbarheden.
Hvad gør vi, hvis vi ikke selv kan vurdere risikoen?
Kontakt jeres platformsleverandør eller en sikkerhedsrådgiver, der kan gennemgå jeres klyngekonfiguration og adgangsrettigheder, og hjælpe med at verificere, om I er sårbare og om der er tegn på udnyttelse.
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)
A flaw was found in the search-v2-operator. This vulnerability allows a privileged user, specifically a Custom Resource (CR) editor, to manipulate Search CR fields such as imageOverride, arguments, and environment variables without proper validation. By exploiting this, an attacker can mount arbitrary secrets into a search container’s environment or replace the container image with an attacker-controlled one. This leads to privilege escalation and can result in a full cluster compromise due to the ServiceAccount’s extensive impersonation permissions.
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.