CVE-2026-66788: Kritisk fejl i Lighthouse (Submariner)
Kritisk sårbarhed i Lighthouse lader angribere med adgang til en spoke-klynge indsprøjte falske netværksressourcer i systemkritiske navnerum på andre klynger. Opdatér eller isolér broker-adgangen.
Hvad er det?
CVE-2026-66788 er en fejl i Lighthouse, en komponent i Submariner-projektet, der binder flere Kubernetes-klynger sammen så tjenester kan finde hinanden på tværs af klynger. Fejlen ligger i CWE-284, en mangelfuld adgangskontrol: navnerummet, det logiske afgrænsede område i en klynge hvor en ressource placeres, bliver bestemt af et mærkat eller en annotation på broker-objektet. Broker-objektet er det centrale styringspunkt, der koordinerer service discovery mellem klyngerne. En angriber, der har kompromitteret en tilknyttet spoke-klynge, kan sætte dette mærkat til at pege på et vilkårligt navnerum, herunder systemkritiske navnerum som kube-system og openshift-*, og derved indsprøjte falske EndpointSlices og ServiceImports, som er de objekter Kubernetes bruger til at oversætte tjenestenavne til netværksadresser.
Hvem rammer det?
Sårbarheden rammer virksomheder og kommuner, der driver flere Kubernetes- eller OpenShift-klynger sammenbundet med Submariner og bruger Lighthouse til service discovery mellem klyngerne. Det gælder typisk organisationer med hybrid eller multi-cloud drift, hvor en klynge lokalt (on-prem) er forbundet til klynger i det offentlige eller private skyer. NVD-data angiver ikke specifikke versionsnumre for de ramte produkter.
Hvad kan ske?
En angriber, der allerede har fået fodfæste i en af de tilknyttede spoke-klynger, kan bruge fejlen til at placere falske netværksobjekter i systemnavnerum på andre klynger i sammenslutningen. Det kan bruges til at omdirigere trafik, udgive sig for interne systemtjenester eller opnå rettighedseskalering, altså skaffe sig højere adgangsrettigheder end tiltænkt, og dermed kompromittere hele klyngefællesskabet fra ét svagt punkt.
Hvor alvorligt er det?
CVSS-scoren er 9,9 ud af 10, hvilket er kritisk. Angrebet kan ske over netværket, kræver lav kompleksitet og kun lave rettigheder, forudsat at angriberen allerede har kompromitteret en spoke-klynge. Der kræves ingen brugerhandling, og konsekvensen er fuld påvirkning af fortrolighed, integritet og tilgængelighed. NVD-data indeholder ingen oplysninger om, at fejlen aktivt udnyttes i praksis.
Hvad gør jeg nu?
Sådan lukker I hullet og begrænser skaden, hvis I kører Submariner og Lighthouse:
- Opdatér Submariner og Lighthouse til den nyeste version, når producenten frigiver en rettelse, der validerer navnerum uafhængigt af mærkater på broker-objektet.
- Er der ingen rettelse tilgængelig endnu, begræns hvilke klynger der kan sende data til broker-objektet, og indfør netværkspolitikker der isolerer trafikken mellem spoke-klynger og hub.
- Gennemgå rettighederne på broker-objektet, så kun betroede systemkonti kan sætte mærkater og annotationer på det.
- Undersøg logs for uventede EndpointSlices eller ServiceImports i systemnavnerum som kube-system og openshift-*.
- Overvåg alle spoke-klynger for tegn på kompromittering, da fejlen først kan udnyttes efter et forudgående indbrud i en klynge.
- Er I i tvivl om jeres multi-cluster-opsætning eller mangler ressourcer til at gennemgå adgangsstyringen, bør I hente teknisk hjælp udefra.
Opdatér når rettelse foreligger, isolér nu
Vi anbefaler, at organisationer med multi-cluster Kubernetes eller OpenShift straks gennemgår adgangsstyringen på broker-objektet og begrænser, hvilke klynger der kan sende mærkater og annotationer til det. Det er i orden at afvente en officiel rettelse, hvis I i mellemtiden har indført netværksisolering mellem spoke-klynger og hub-klyngen. Har I ikke overblik over jeres Submariner-opsætning, bør det klarlægges, før I venter længere.
Tidslinje
Konkrete eksempler
Kommune med fælles Kubernetes-drift
En kommune driver flere Kubernetes-klynger sammenbundet med Submariner for at dele borgerservicer mellem et lokalt datacenter og en offentlig sky. En angriber udnytter en anden svaghed til at kompromittere den lokale spoke-klynge og bruger derefter denne fejl til at indsprøjte falske serviceobjekter i systemnavnerummet på hub-klyngen, hvorved trafik fra andre klyngers borgerserviceløsninger kan omdirigeres.
Ofte stillede spørgsmål
Er vi ramt af denne sårbarhed?
I er kun ramt, hvis I bruger Submariner med Lighthouse til at forbinde flere Kubernetes- eller OpenShift-klynger. Kører I en enkelt klynge uden multi-cluster service discovery, er jeres system ikke berørt.
Hvordan tjekker vi, om vi bruger Lighthouse?
Tjek om Submariner er installeret som operator eller Helm-chart i jeres klynger, og om der findes broker-objekter og EndpointSlices med Lighthouse-relaterede mærkater i navnerummet submariner-operator.
Kan vi vente til weekenden med at gøre noget?
Ja, hvis I i mellemtiden indfører netværkspolitikker der begrænser, hvilke klynger der kan skrive til broker-objektet. Har I ikke mulighed for det, bør adgangsstyringen strammes samme dag som sårbarheden er kendt.
Kræver angrebet, at vi allerede er hacket?
Ja, angriberen skal først have kompromitteret en af de tilknyttede spoke-klynger. Sårbarheden er derfor et andet led i et angreb, ikke den indledende indgang, men kan bruges til at eskalere en begrænset kompromittering til fuld kontrol over klyngefællesskabet.
Skal vi anmelde dette til myndighederne?
Kun hvis fejlen fører til et konstateret sikkerhedsbrud med adgang til persondata eller kritisk infrastruktur. Sårbarheden i sig selv, uden tegn på udnyttelse, udløser ikke anmeldelsespligt.
Hvad koster det at vente med at rette op på adgangsstyringen?
Ventetiden øger risikoen for, at en enkelt kompromitteret klynge bruges som springbræt til at overtage systemkritiske navnerum i hele klyngefællesskabet, hvilket kan påvirke drift og data i alle forbundne miljøer.
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.
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.