CVE-2026-70496: Kritisk rettighedsfejl i search-v2-operator
Operatoren search-v2-operator har fejlagtigt rettigheder som klyngeadministrator i Kubernetes. Begræns adgang og opdatér, så snart en rettelse findes.
Hvad er det?
CVE-2026-70496 er en fejl i søgeoperatoren search-v2-operator, der bruges i Kubernetes-klynger. Operatorens ClusterRole, en samling af tilladelser i Kubernetes, er sat op med samme niveau som en klyngeadministrator. Det betyder, at operatoren kan udgive sig for andre identiteter i klyngen, skrive nye adgangsregler (RBAC), godkende certifikatanmodninger og styre andre komponenters arbejde. Ingen af disse rettigheder er nødvendige for, at operatoren kan udføre sin egentlige opgave, som er søgefunktionalitet. Fejlen kaldes overprivilegering og betyder, at en angriber, der får blot begrænset adgang til operatoren, kan bruge dens brede rettigheder til at tage kontrol over hele klyngen.
Hvem rammer det?
Fejlen rammer organisationer, der driver Kubernetes- eller OpenShift-klynger med search-v2-operator installeret. Det gælder både virksomheder og kommuner, der bruger container-platforme til drift af egne eller leverede løsninger. NVD har ikke angivet konkrete berørte versioner, så I bør kontrollere jeres klyngeopsætning direkte for at se, om operatoren er installeret.
Hvad kan ske?
En angriber, der allerede har opnået lav adgang til klyngen, for eksempel via en kompromitteret container eller en stjålet service-konto, kan udnytte operatorens brede rettigheder til at hæve sine egne rettigheder til klyngeadministrator. Herfra kan angriberen læse og ændre alle hemmeligheder i klyngen, tage kontrol over andre applikationer og potentielt få adgang til data og systemer, som klyngen driver for hele organisationen.
Hvor alvorligt er det?
CVSS-scoren er 9,9 ud af 10, hvilket er kritisk. Angrebet kræver ingen brugerinteraktion og har lav teknisk kompleksitet, men angriberen skal have en vis eksisterende adgang til klyngen (lav privilegeret adgang). Der er ikke oplysninger om, at fejlen udnyttes aktivt på nuværende offentliggørelsesdato, men fordi konsekvensen er fuld kontrol over klyngen, bør den prioriteres højt.
Hvad gør jeg nu?
Følgende trin lukker eller reducerer risikoen, indtil en officiel rettelse foreligger.
- Kontrollér, om search-v2-operator er installeret i jeres klynger, og opdatér til en rettet version, så snart leverandøren udgiver en.
- Gennemgå operatorens ClusterRole og fjern eller begræns tilladelser til impersonation, RBAC-skrivning, CSR-godkendelse og ManifestWork-styring, hvis det er muligt uden at ødelægge funktionaliteten.
- Begræns, hvem og hvad der kan tilgå operatorens service-konto, og isolér den fra andre navnerum i klyngen.
- Overvåg klyngens logs for uventet brug af impersonation, RBAC-ændringer eller certifikatgodkendelser.
- Tag kontakt til jeres platformsleverandør eller sikkerhedsrådgiver, hvis I ikke selv har kompetencer til at vurdere eller justere Kubernetes RBAC-opsætning.
Opdatér, når rettelse er tilgængelig
Vi anbefaler, at I straks kortlægger, om search-v2-operator kører i jeres Kubernetes-miljø, og begrænser dens rettigheder mest muligt, mens I afventer en officiel rettelse. Det er ikke forsvarligt at vente til en fast opdateringscyklus, fordi konsekvensen ved udnyttelse er fuld kontrol over klyngen. Har I ikke egne kompetencer til at ændre RBAC-opsætning uden at bryde driften, bør I hente ekstern hjælp nu.
Tidslinje
Konkrete eksempler
Kompromitteret container eskalerer til klyngeadministrator
En dansk kommune driver en Kubernetes-klynge med search-v2-operator installeret som del af deres platform. En angriber udnytter en sårbarhed i en anden applikation i klyngen og opnår adgang til en container med lave rettigheder. Fra denne container bruger angriberen operatorens overprivilegerede ClusterRole til at udgive sig for en administrator, godkender egne certifikatanmodninger og opnår fuld kontrol over klyngen, herunder adgang til borgerdata i andre systemer, der kører i klyngen.
Ofte stillede spørgsmål
Er vi ramt af denne sårbarhed?
I er ramt, hvis jeres Kubernetes- eller OpenShift-klynge har search-v2-operator installeret. Tjek jeres liste over installerede operatorer og ClusterRoles i klyngen for at bekræfte det.
Kan vi vente til en almindelig opdateringsrunde?
Det bør I ikke. CVSS-scoren er 9,9, og konsekvensen ved udnyttelse er fuld kontrol over klyngen. Vi anbefaler, at I begrænser operatorens rettigheder nu, uanset hvornår en officiel rettelse kommer.
Kræver angrebet, at en medarbejder klikker på noget?
Nej. Fejlen kræver ingen brugerinteraktion. Angriberen skal dog allerede have en vis lav-privilegeret adgang til klyngen, for eksempel via en kompromitteret container eller service-konto.
Hvordan kontrollerer vi, om operatoren har for brede rettigheder?
I kan undersøge operatorens ClusterRole og se, hvilke tilladelser den har til impersonation, RBAC-skrivning, godkendelse af certifikatanmodninger og styring af ManifestWork. Har den flere rettigheder end nødvendigt for søgefunktionen, er I berørt.
Skal vi anmelde dette til myndighederne?
Kun hvis fejlen faktisk udnyttes, og det medfører et sikkerhedsbrud med adgang til persondata. I det tilfælde er I forpligtet til at vurdere anmeldelse efter databeskyttelsesreglerne. Forebyggende afdækning og lukning af sårbarheden udløser ikke i sig selv en anmeldelsespligt.
Hvad gør vi, hvis vi ikke selv kan ændre RBAC-opsætningen?
Kontakt jeres platformsleverandør eller en sikkerhedsrådgiver. Forkert ændring af RBAC kan ødelægge driften, så det er vigtigt at få kvalificeret hjælp, hvis I er i tvivl.
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 search-v2-operator. The operator’s ClusterRole has permissions equivalent to a cluster administrator, allowing it to impersonate other entities, write Role-Based Access Control (RBAC) configurations, approve Certificate Signing Requests (CSRs), and manage ManifestWork. This grants excessive privileges beyond what is necessary for the operator’s intended function, potentially leading to privilege escalation within the cluster.
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.