CVE-2026-58172: Kritisk sårbarhed i Ocelot API Gateway
Kritisk sårbarhed i Ocelot API Gateway lader blokerede IP-adresser omgå adgangskontrol via WebSocket-forbindelser.
Hvad er det?
Ocelot er et populært open source API Gateway-produkt (et trafikstyringsværktøj der sidder foran dine bagsystemer og kontrollerer hvem der må tale med hvad). I versioner op til og med 24.1.0 er der en fejl i den måde, Ocelot håndterer WebSocket-forbindelser (en type realtidsforbindelser brugt af f.eks. chat, notifikationer og live-data) på. Normalt blokerer Ocelot IP-adresser (netværksadresser for computere), der ikke er på tilladelseslisten. Men hvis en angriber beder om en WebSocket-forbindelse i stedet for en normal HTTP-forespørgsel, springer Ocelot fejlagtigt sikkerhedskontrollen over — og videresender anmodningen direkte til dine bagsystemer, som om den kom fra en tilladt kilde.
Hvem rammer det?
Sårbarheden rammer virksomheder og udviklere der:
- Bruger Ocelot som API Gateway i deres .NET-baserede applikationer eller systemer
- Har konfigureret IP-baserede adgangsbegrænsninger i Ocelot (allow/block-lister)
- Eksponerer WebSocket-endepunkter (realtidsforbindelser) gennem Ocelot
Bruger du ikke Ocelot, eller har du ikke IP-baserede adgangsbegrænsninger konfigureret, er du ikke direkte berørt af denne specifikke sårbarhed.
Hvad kan ske?
Hvis en angriber udnytter denne sårbarhed, kan vedkommende:
- Omgå dine adgangsbegrænsninger — selv hvis en IP-adresse er eksplicit blokeret, kan angriberen komme igennem alligevel
- Tilgå fortrolige data — bagsystemer der burde være beskyttet kan blive eksponeret for uautoriserede parter (høj fortrolighedsrisiko)
- Manipulere data eller funktioner — angriberen kan sende uautoriserede kommandoer til dine interne systemer (høj integritetspåvirkning)
Det er vigtigt at bemærke, at selve tjenesternes tilgængelighed (oppetid) ikke er direkte truet af denne sårbarhed — men de data og funktioner der ligger bag kan altså nås uden tilladelse.
Hvor alvorligt er det?
Sårbarheden er vurderet som kritisk med en CVSS-score på 9,1 ud af 10. Det skyldes flere faktorer:
- Netværksbaseret angreb: Angriberen behøver ikke fysisk adgang — angrebet kan udføres over internettet
- Lav kompleksitet: Der kræves ingen særlige tekniske færdigheder eller specielle betingelser for at udnytte fejlen
- Ingen autentifikation nødvendig: Angriberen behøver hverken brugernavn, adgangskode eller særlige rettigheder
- Ingen brugerinteraktion: Dine medarbejdere behøver ikke klikke på noget — angrebet sker helt automatisk
CWE-288 betegner netop denne type fejl: en sikkerhedskontrol der omgås via en alternativ adgangsvej, som i dette tilfælde er WebSocket-protokollen.
Hvad gør jeg nu?
Følg disse trin så hurtigt som muligt:
- Identificér om du bruger Ocelot: Spørg din IT-ansvarlige eller udvikler om jeres systemer anvender Ocelot som API Gateway, og hvilken version der kører.
- Opdatér til den rettede version: Fejlen er udbedret i commit f156fd4 i Ocelots kildekode. Sørg for at jeres Ocelot-installation er opdateret til en version der indeholder denne rettelse (efter 24.1.0).
- Gennemgå jeres IP-adgangslister: Bekræft at jeres allow/block-lister er konfigureret korrekt efter opdateringen, og at de nu også gælder for WebSocket-forbindelser.
- Overvåg for mistænkelig aktivitet: Gennemgå logfiler fra perioden før opdateringen for usædvanlige WebSocket-forbindelser fra IP-adresser der burde have været blokeret.
- Vurder eksponering: Har I WebSocket-endepunkter eksponeret mod internettet via Ocelot? I så fald er risikoen størst — prioritér opdateringen derefter.
Opdatér inden for 24-72 timer
Med en CVSS-score på 9,1 og en fejl der kan udnyttes uden særlige tekniske forudsætninger, anbefaler vi at I behandler dette som en hasteopgave. Kontakt jeres IT-leverandør eller interne udvikler i dag og få bekræftet om I bruger Ocelot — og i hvilken version. Rettelsen er allerede tilgængelig, så der er ingen grund til at vente. Opdatér hurtigst muligt og tjek efterfølgende jeres logs for tegn på misbrug.
Tidslinje
Konkrete eksempler
Angriber omgår IP-blokering mod internt adminsystem
En virksomhed har konfigureret Ocelot til kun at tillade adgang til deres interne administrationsAPI fra specifikke kontor-IP-adresser. En angriber fra en fremmed IP-adresse sender en WebSocket-opgraderingsanmodning i stedet for en normal HTTP-forespørgsel. Ocelot springer sikkerhedskontrollen over og videresender anmodningen direkte til administrationssystemet — angriberen kan nu læse og ændre data, som om vedkommende sad på kontoret.
Automatiseret scanning udnytter åbningen
Et automatiseret hackerværktøj scanner internettet for Ocelot-installationer og forsøger systematisk at sende WebSocket-opgraderingsanmodninger mod kendte API-endepunkter. Fordi angrebet kræver ingen autentifikation og lav teknisk kompleksitet, kan scanning og udnyttelse ske fuldt automatisk uden menneskelig indgriben fra angriberens side — virksomheden opdager det måske slet ikke, før data allerede er blevet tilgået.
Konkurrent eller insider tilgår forretningskritiske data
En tidligere medarbejder eller ekstern konkurrent kender virksomhedens API-struktur og ved at deres IP-adresse er blokeret. Ved at skifte til en WebSocket-forbindelsesanmodning omgår vedkommende blokeringen og tilgår f.eks. kundedata, prislister eller ordrehistorik fra bagsystemerne. Fortrolige forretningsoplysninger kan dermed eksfiltreres (kopieres ud) uden at de normale adgangskontroller slår til.
Ofte stillede spørgsmål
Hvad er Ocelot, og ved jeg om vi bruger det?
Ocelot er et open source-bibliotek til .NET-platforme, der bruges som API Gateway — et mellemled der styrer trafikken til jeres interne systemer. Det bruges typisk af virksomheder der har udviklet egne digitale løsninger eller applikationer. Spørg jeres IT-ansvarlige eller softwareudvikler om I anvender Ocelot, og se eventuelt i jeres systemer efter NuGet-pakken ‘Ocelot’.
Er vi i fare, selv hvis vi ikke bruger WebSockets aktivt?
Potentielt ja. En angriber kan selv sende en WebSocket-opgraderingsanmodning mod jeres Ocelot-gateway — I behøver ikke selv at bruge WebSockets. Bare det at Ocelot er konfigureret til at håndtere dem (hvilket er standard), kan være nok til at angrebet lykkes. Opdatering er den sikre løsning uanset jeres brug af WebSockets.
Hvad er forskellen på en API Gateway og en firewall?
En firewall (brandmur) er et netværkssikkerhedslag der kontrollerer hvilken trafik der overhovedet må ind i jeres netværk. En API Gateway som Ocelot sidder et lag inden i og styrer hvilke forespørgsler der viderestilles til hvilke interne systemer. Denne sårbarhed handler om API Gateway-laget — selv hvis jeres firewall er korrekt konfigureret, kan angrebet stadig ramme jer, da det sker på et andet niveau.
Kan vi midlertidigt beskytte os uden at opdatere?
En mulig midlertidig foranstaltning er at blokere indgående WebSocket-opgraderingsanmodninger (HTTP-header ‘Upgrade: websocket’) på netværks- eller firewall-niveau, indtil I får opdateret Ocelot. Dette kan dog påvirke funktionalitet der legitimt benytter WebSockets. Tal med jeres IT-leverandør om hvad der er realistisk i jeres miljø — men den rigtige løsning er at opdatere.
Hvordan ved jeg om vi allerede er blevet angrebet?
Gennemgå jeres Ocelot-logfiler og netværkslogs for WebSocket-forbindelser (forespørgsler med ‘Upgrade: websocket’ i headeren) der kom fra IP-adresser, som burde have været blokeret. Hvis I ser trafik fra blokerede adresser der alligevel nåede jeres bagsystemer, kan det være et tegn på udnyttelse. Kontakt en sikkerhedsekspert hvis I er i tvivl om hvad I ser.
Gælder rettelsen også fremtidige versioner af Ocelot?
Ja. Fejlen er rettet i commit f156fd4 i Ocelots officielle kildekode. Alle versioner af Ocelot der er udgivet efter denne rettelse, indeholder den korrekte sikkerhedskontrol for WebSocket-forbindelser. Sørg for at holde Ocelot opdateret fremover, og følg med i officielle sikkerhedsopdateringer fra projektet på GitHub.
Ramte produkter
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
Ocelot through 24.1.0, fixed in commit f156fd4, contains a security control bypass vulnerability that allows denied clients to circumvent IP-based access restrictions by sending WebSocket upgrade requests. The WebSocket upgrade pipeline branch configured via MapWhen in OcelotPipelineExtensions.cs omits SecurityMiddleware, causing requests from blocked IP addresses to be proxied to downstream services without enforcement of the configured allow/block list.
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.