CVE-2026-66785: Kritisk fejl i Submariner netværk
Fejl i Submariner lader en tilsluttet Kubernetes-klynge omdirigere andre klyngers netværkstrafik. Opdatér straks.
Hvad er det?
CVE-2026-66785 er en fejl i Submariner, et værktøj der forbinder netværket mellem flere Kubernetes-klynger, så de kan dele tjenester og trafik. Fejlen skyldes mangelfuld inputvalidering (CWE-20): systemet kontrollerer ikke, om en tilsluttet klynge angiver ægte netværksområder, når den registrerer sig. En ondsindet klynge kan derfor udgive sig for at eje vilkårlige IP-områder. Trafik fra andre klynger i samme netværk, som skulle gå til disse områder, bliver i stedet ledt gennem angriberens tunnel. Det kan betyde, at fortrolige data læses eller ændres, eller at trafikken helt afbrydes.
Hvem rammer det?
Rammer organisationer, der bruger Submariner til at koble flere Kubernetes-klynger sammen, typisk virksomheder og offentlige institutioner med drift spredt over flere datacentre, skyudbydere eller et hybrid-miljø. Alle klynger, der er tilsluttet samme Submariner-fællesskab (broker), er udsat, hvis blot én af de tilsluttede klynger er kompromitteret eller drives af en part, man ikke fuldt ud kan stole på.
Hvad kan ske?
En dansk virksomhed med flere Kubernetes-klynger, fx en produktionsklynge og en testklynge forbundet via Submariner, risikerer at trafik fra produktionsklyngen bliver omdirigeret gennem en angrebet eller kompromitteret klynge. Det giver mulighed for at aflytte eller ændre data, der sendes mellem klynger, og kan bruges til at afbryde forbindelsen mellem systemer, der er afhængige af hinanden.
Hvor alvorligt er det?
CVSS-score er 9,9 ud af 10, hvilket er kritisk. Angrebet kræver ikke brugerinteraktion og udføres over netværket. Angriberen skal have en lav grad af rettigheder, i praksis skal de kunne registrere en klynge i det samme Submariner-fællesskab. Konsekvensen rammer fortrolighed, integritet og driftsstabilitet fuldt ud, og fejlen påvirker også ressourcer uden for den kompromitterede klynge (scope changed). Der er ikke oplysninger om, at fejlen aktivt udnyttes i angreb.
Hvad gør jeg nu?
Følgende punkter bør gennemgås i den anførte rækkefølge:
- Opdatér Submariner til den version, hvor validering af netværksområder (subnets) er rettet. Tjek projektets udgivelsesnoter for den konkrete version.
- Gennemgå, hvilke klynger der er tilsluttet jeres Submariner-fællesskab, og fjern klynger, I ikke længere har brug for eller ikke kan stå inde for.
- Begræns adgangen til at tilslutte nye klynger til fællesskabet, så kun godkendte administratorer kan gøre det.
- Overvåg netværkstrafikken mellem klynger for uventede ruter eller trafik, der går gennem klynger, den ikke burde.
- Dokumentér, hvilke klynger der har adgang til hvilke tjenester, så I hurtigt kan vurdere omfanget, hvis noget alligevel går galt.
- Hvis I ikke har ressourcer til selv at vurdere jeres Submariner-opsætning, bør I hente hjælp udefra til gennemgangen.
Opdatér inden for få dage
Vi anbefaler, at I straks kortlægger, hvilke klynger der er tilsluttet jeres Submariner-fællesskab, og opdaterer så snart en rettet version er tilgængelig. Det er kun forsvarligt at vente, hvis I kan dokumentere, at alle tilsluttede klynger er under jeres egen kontrol og ikke deler adgang med eksterne parter. I alle andre tilfælde bør gennemgangen ske uden unødig forsinkelse, da konsekvensen ved misbrug er høj.
Tidslinje
Konkrete eksempler
Multi-cluster drift i en dansk virksomhed
En dansk virksomhed driver Kubernetes-klynger i to datacentre, forbundet via Submariner for at dele interne tjenester. En af klyngerne, driftet af en samarbejdspartner, bliver kompromitteret. Angriberen registrerer et falsk netværksområde, der overlapper med virksomhedens interne systemer, og trafik med kundedata bliver dermed sendt gennem angriberens tunnel, uden at nogen af parterne opdager det umiddelbart.
Ofte stillede spørgsmål
Er vi ramt af denne sårbarhed?
I er kun ramt, hvis jeres organisation bruger Submariner til at forbinde flere Kubernetes-klynger. Tjek om Submariner er installeret, og om der er tilsluttet klynger, I ikke selv fuldt ud kontrollerer.
Kan vi vente til efter weekenden med at opdatere?
Det afhænger af, hvor mange og hvilke klynger der er tilsluttet jeres fællesskab. Har I klynger drevet af tredjeparter eller mindre betroede enheder, bør opdateringen prioriteres inden weekenden. Er alle klynger internt kontrollerede, kan det vente kort tid, men bør stadig planlægges hurtigt.
Hvordan tjekker vi, om vores opsætning er sårbar?
Gennemgå listen over tilsluttede klynger i jeres Submariner-broker og se, hvilke netværksområder hver klynge har registreret. Uventede eller overlappende netværksområder kan være tegn på misbrug.
Skal vi anmelde noget til myndighederne?
Hvis I finder tegn på, at trafik faktisk er blevet omdirigeret eller data er kompromitteret, kan det udløse anmeldelsespligt efter reglerne om databeskyttelse eller NIS2, afhængig af jeres sektor. Kontakt jeres databeskyttelsesrådgiver for en konkret vurdering.
Kræver det, at angriberen har adgang i forvejen?
Ja, angriberen skal kunne registrere en klynge i samme Submariner-fællesskab, hvilket kræver en form for adgang eller tillid til fællesskabet. Det gør fejlen særligt relevant for organisationer, der deler netværksinfrastruktur med eksterne parter eller partnere.
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 Submariner. This vulnerability allows a malicious cluster (spoke) to redirect network traffic from other connected clusters (peer clusters) by publishing a specially crafted network endpoint. The system fails to properly validate the network subnets provided by the malicious cluster, enabling it to declare arbitrary network ranges. Consequently, all network traffic intended for these arbitrary ranges from peer clusters will be rerouted through the attacker’s tunnel, potentially leading to unauthorized information disclosure or network disruption.
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.