CVE-2026-66788: Kritisk fejl i Lighthouse/Submariner
Kritisk fejl i Lighthouse lader angribere injicere netværksressourcer i alle namespaces – inklusive systemkritiske områder.
Hvad er det?
Lighthouse er en komponent i Submariner-projektet, der bruges til at forbinde flere Kubernetes-klynger (grupper af servere) med hinanden på tværs af netværk. En kritisk fejl i Lighthouse betyder, at en angriber, der allerede har kompromitteret én klynge (en såkaldt ‘spoke cluster’), kan manipulere et felt på et netværksobjekt kaldet en ‘broker’. Fordi Lighthouse ukritisk stoler på dette felt, kan angriberen bestemme, hvor i systemet nye netværksressourcer (EndpointSlices og ServiceImports) placeres – herunder i beskyttede systemområder som kube-system. Det svarer til, at en uautoriseret person kan flytte ind i en aflåst del af bygningen ved blot at sætte en falsk etiket på sin nøgle.
Hvem rammer det?
Sårbarheden rammer virksomheder og organisationer, der bruger Kubernetes med Submariner/Lighthouse til at forbinde flere klynger på tværs af miljøer eller cloud-udbydere. Det er typisk:
- Teknologivirksomheder og SaaS-leverandører med multi-cloud-opsætninger
- Offentlige og private organisationer, der bruger OpenShift (Red Hats Kubernetes-platform)
- Udviklingshold, der kører distribuerede containerbaserede applikationer
Har din virksomhed ikke Kubernetes eller Submariner, er du ikke direkte ramt.
Hvad kan ske?
Hvis sårbarheden udnyttes, kan en angriber, der allerede har fodfæste i én klynge, eskalere sine rettigheder (få administratoradgang) i andre tilknyttede klynger. Konkret kan det betyde:
- Privilegieeskalering: Angriberen opnår kontrol over systemkritiske namespaces som
kube-systemelleropenshift-*. - Datalæk: Adgang til fortrolige data, hemmeligheder og konfigurationer på tværs af klynger.
- Systemkompromittering: Mulighed for at afbryde, manipulere eller overtage tjenester i hele klynge-netværket.
- Lateral bevægelse: Angriberen kan bevæge sig fra én kompromitteret klynge til alle forbundne klynger.
Hvor alvorligt er det?
Denne sårbarhed er vurderet til 9,9 ud af 10 (Kritisk) af det internationale sikkerhedssystem CVSS. Det er næsten den højest mulige score. Årsagen til den høje score er:
- Netværksbaseret angreb: Angriberen behøver ikke fysisk adgang – angrebet sker over netværket.
- Lav kompleksitet: Det kræver ikke avancerede færdigheder at udnytte fejlen.
- Lave krav til rettigheder: Angriberen behøver kun begrænsede rettigheder i én klynge for at angribe alle andre.
- Fuld CIA-impact: Fortrolighed, integritet og tilgængelighed af data er alle i spil (C/I/A = HIGH).
- Scope-ændring: Angrebet kan brede sig ud over den oprindeligt kompromitterede klynge.
Hvad gør jeg nu?
Følg disse trin for at beskytte din virksomhed hurtigst muligt:
- Kortlæg din eksponering: Undersøg om din virksomhed bruger Submariner eller Lighthouse i jeres Kubernetes-miljø. Spørg jeres IT-afdeling eller cloud-leverandør.
- Tjek for tilgængelig patch: Følg Submariner-projektets officielle sikkerhedsbulletiner og GitHub-releases for en opdatering, der adresserer CVE-2026-66788. Installer opdateringen straks, når den er tilgængelig.
- Begræns adgang til spoke-klynger: Gennemgå hvem og hvad der har adgang til jeres klynger. Fjern unødvendige rettigheder (princippet om mindste privilegium).
- Overvåg for mistænkelig aktivitet: Sæt alarmering op på ændringer i namespaces som
kube-systemogopenshift-*, herunder oprettelse af nye EndpointSlices og ServiceImports. - Isolér kompromitterede klynger: Hvis I har mistanke om kompromittering, bør I midlertidigt isolere den pågældende klynge fra resten af netværket, mens I undersøger hændelsen.
- Kontakt jeres IT-sikkerhedsleverandør: Hvis I er usikre på eksponering eller afhjælpning, bør I kontakte en IT-sikkerhedskonsulent med Kubernetes-erfaring.
Handl inden for 24-48 timer
Med en CVSS-score på 9,9 er dette en af de mest alvorlige sårbarheder, vi anbefaler at prioritere øjeblikkeligt. Selvom udnyttelse kræver forudgående adgang til én klynge, er konsekvenserne ved et vellykket angreb ekstremt alvorlige, da alle forbundne klynger risikerer at blive kompromitteret. Vi anbefaler, at du straks kortlægger din brug af Submariner/Lighthouse, begrænser adgangen til dine klynger og holder øje med patches fra Submariner-projektet. Kontakt os, hvis du har brug for hjælp til at vurdere din eksponering eller implementere midlertidige beskyttelsesforanstaltninger.
Tidslinje
kube-system og openshift-*.Konkrete eksempler
Angriber eskalerer fra én klynge til alle
En angriber opnår adgang til en mindre, ekstern spoke-klynge i en virksomheds multi-cloud-opsætning – for eksempel via en lækket API-nøgle. Angriberen ændrer en etiket (label) på et broker-objekt og narrer Lighthouse til at injicere falske ServiceImports i kube-system-namespacet på alle andre tilknyttede klynger. Herigennem opnår angriberen administratoradgang til hele klynge-netværket og kan nu tilgå alle data og tjenester på tværs af virksomhedens cloud-miljøer.
Trafikomdirigering og dataaflytnig
En angriber med fodfæste i en spoke-klynge indsætter falske EndpointSlices, der peger på en server under angriberens kontrol. Trafikken fra andre klynger – herunder kald med fortrolige data som API-tokens og brugercredentials – sendes nu til angriberens server i stedet for den legitime destination. Virksomheden opdager ikke angrebet, da alt tilsyneladende fungerer normalt for slutbrugerne.
Sabotage af kritiske systemkomponenter
En angriber bruger sårbarheden til at injicere manipulerede ressourcer i openshift-monitoring-namespacet. Dette forstyrrer overvågningssystemet, der stopper med at sende alarmer. Angriberen kan herefter gennemføre yderligere angreb – for eksempel ransomware-udrulning – uden at virksomhedens sikkerhedsteam modtager advarsler i realtid.
Ofte stillede spørgsmål
Bruger vi Lighthouse, uden at vi ved det?
Lighthouse er en del af Submariner-projektet og bruges typisk kun, hvis din virksomhed bevidst har sat det op til at forbinde Kubernetes-klynger. Det er ikke en komponent, der installeres automatisk. Spørg din IT-afdeling, om I bruger Submariner, eller tjek jeres Kubernetes-konfiguration for namespaces som
submariner-operator.Er vi i fare, selvom angriberen ikke kender vores systemer?
For at udnytte denne sårbarhed skal angriberen allerede have kompromitteret én af jeres spoke-klynger. Det betyder, at risikoen er størst, hvis én klynge allerede er i fare. Har I en stærk adgangskontrol og overvågning på alle jeres klynger, reducerer det risikoen for, at en angriber kan nå dette trin.
Hvad er EndpointSlices og ServiceImports, og hvorfor er det farligt?
EndpointSlices og ServiceImports er Kubernetes-netværksobjekter, der fortæller klyngen, hvordan trafik skal routes (sendes) til tjenester på tværs af klynger. Hvis en angriber kan injicere falske sådanne objekter i systemkritiske namespaces, kan de omdirigere trafik, aflytte kommunikation eller eskalere egne rettigheder i systemet.
Hvad gør vi, hvis der endnu ikke er en patch?
Indtil en officiel patch er tilgængelig, bør I begrænse adgangen til broker-objekter og spoke-klynger mest muligt. Overvej at deaktivere Lighthouse midlertidigt, hvis det er muligt uden at ramme kritiske forretningsprocesser. Opsæt skærpet overvågning på systemkritiske namespaces og vær klar til at handle hurtigt, når en patch frigives.
Gælder dette kun OpenShift, eller alle Kubernetes-miljøer?
Sårbarheden gælder alle Kubernetes-miljøer, der bruger Lighthouse/Submariner. OpenShift nævnes specifikt, fordi systemnamespaces som
openshift-*er særligt kritiske mål. Bruger I standard Kubernetes eller en anden distribution med Submariner, er I også potentielt sårbare.Skal vi informere vores kunder om denne sårbarhed?
Hvis jeres Kubernetes-klynger behandler kundedata, og I har mistanke om, at sårbarheden er blevet udnyttet, kan I have en notifikationspligt i henhold til GDPR. Kontakt jeres DPO (databeskyttelsesansvarlig) og juridiske rådgiver for at vurdere, om og hvornår I skal informere kunder og eventuelt Datatilsynet.
Ramte produkter
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 Lighthouse. A remote attacker, by compromising a spoke cluster, can exploit a vulnerability where the destination namespace for resource injection is derived from an attacker-controlled label or annotation on the broker object. This allows the attacker to inject unauthorized EndpointSlices and ServiceImports into any namespace on peer clusters, including critical system namespaces like kube-system and openshift-*. This could lead to privilege escalation or other forms of system compromise within the cluster.
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.