CVE-2026-92787: Kritisk JWT-fejl i Feast feature store
Feast frem til version 0.66.0 tjekker ikke JWT-signaturer og lader angribere logge ind som betroet bruger uden password. Opdatér nu.
Hvad er det?
CVE-2026-92787 er en fejl i datterplatformen Feast, der bruges til at samle og servere data til maskinlæringsmodeller (en feature store). Systemet skal bekræfte brugeres identitet ved at kontrollere signaturen på en JWT-token, en digitalt underskrevet adgangsbevis. Fejlen betyder, at Feast accepterer en token uden at tjekke, om signaturen er ægte, så længe token indeholder en bestemt, hårdkodet værdi i sit indhold. En angriber kan derfor selv bygge en falsk token med den kendte værdi og blive godkendt som en betroet intern bruger uden at kende nogen adgangskode.
Hvem rammer det?
Sårbarheden rammer alle installationer af Feast i version 0.66.0 og tidligere, hvor rollebaseret adgangskontrol (RBAC) er sat op via JWT-godkendelse. Det gælder virksomheder og kommuner, der bruger Feast som central feature store til maskinlæringsprojekter, typisk data- og analyseteams samt IT-drift, der har eksponeret Feast-serveren på et netværk, interne eller offentlige.
Hvad kan ske?
En angriber, der kan nå Feast-serveren over netværket, kan opnå fuld læse- og skriveadgang til alle entiteter, feature views, datakilder og adgangspolitikker, uden at logge ind med gyldige oplysninger. I praksis betyder det, at angriberen kan stjæle forretningsdata og modeltræningsdata, ændre eller slette datasæt, og omskrive adgangspolitikker, så egne rettigheder udvides yderligere. For en dansk virksomhed kan det føre til datalæk af persondata brugt i modeller, sabotage af produktionssystemer der bygger på Feast-data, og et brud på GDPR, der skal anmeldes.
Hvor alvorligt er det?
CVSS-scoren er 9,8 ud af 10, kritisk. Angrebet kræver ingen login, ingen brugerhandling fra offeret og kan udføres over netværket med lav kompleksitet. Både fortrolighed, integritet og tilgængelighed er fuldt ramt (C=H, I=H, A=H), fordi angriberen får både læse- og skriverettigheder til alt data i systemet. Der er ikke oplyst aktiv udnyttelse i naturen på offentliggørelsesdatoen, men sårbarheden er triviel at udnytte, når man kender den hårdkodede værdi.
Hvad gør jeg nu?
Følgende trin lukker hullet og begrænser skaden, mens I opdaterer.
- Opdatér Feast til en version nyere end 0.66.0, hvor JWT-signaturverifikation er rettet. Tjek release notes fra Feast-projektet for den konkrete version.
- Kan I ikke opdatere med det samme, så afskær ekstern netværksadgang til Feast-serveren, og begræns adgangen til et internt, betroet netværk eller VPN.
- Roter alle JWT-signeringsnøgler og udgivne tokens, så eventuelle allerede udstedte falske tokens ikke længere virker efter opdateringen.
- Gennemgå adgangslogs på Feast-serveren for ukendte klienter, uventede læse- eller skriveoperationer på entiteter og ændringer i permission-policies.
- Vurdér om persondata i feature stores kan være tilgået, og afklar om det udløser en anmeldelsespligt efter GDPR.
- Er I i tvivl om, hvordan RBAC og JWT er sat op hos jer, eller finder I spor af misbrug, bør I tilkalde ekstern sikkerhedshjælp til undersøgelse og hærdning.
Opdatér inden for 24 timer
Vi anbefaler, at I opdaterer Feast til en rettet version med det samme, da angrebet ikke kræver login og kan udføres af enhver, der kan nå serveren. Det er ikke i orden at vente til en planlagt vedligeholdelsesvindue, fordi konsekvensen er fuld adgang til jeres data. Er Feast-serveren kun tilgængelig fra et strengt internt netværk uden ekstern adgang, kan I nøjes med at afskærme adgangen midlertidigt, mens opdateringen planlægges, men det bør ske inden for få dage, ikke uger.
Tidslinje
Konkrete eksempler
Adgang til modeldata i en dansk fintech-virksomhed
Et dansk fintech-selskab bruger Feast som feature store til deres kreditvurderingsmodeller, tilgængelig internt på deres netværk. En angriber, der har fået fodfæste et andet sted på netværket, opdager Feast-serveren og sender en selvbygget token med den hårdkodede claim-værdi. Angriberen får dermed fuld adgang til at læse kundedata brugt i modellerne og ændre feature views, hvilket kan påvirke fremtidige kreditbeslutninger og udløse en GDPR-anmeldelse.
Ofte stillede spørgsmål
Er vi ramt af CVE-2026-92787?
I er ramt, hvis I kører Feast i version 0.66.0 eller tidligere med JWT-baseret RBAC aktiveret. Tjek jeres Feast-version og konfigurationsfilen for auth-opsætning for at bekræfte.
Hvordan tjekker vi, om vi er udnyttet?
Gennemgå adgangslogs på Feast-serveren for tokens med usædvanlige eller genkendelige hårdkodede claim-værdier, og se efter uventede læse- eller skrivehandlinger på entiteter, feature views og permission-policies fra ukendte klienter eller IP-adresser.
Kan vi vente med opdateringen til weekenden?
Det kan I kun, hvis Feast-serveren er fuldt afskærmet fra eksterne og interne uvedkommende netværk i mellemtiden. Er serveren tilgængelig fra et bredere netværk, bør opdateringen ske hurtigst muligt, da sårbarheden er let at udnytte.
Skal vi anmelde dette som et databrud?
Hvis Feast-serveren har behandlet persondata, og I finder tegn på uautoriseret adgang, skal I vurdere anmeldelsespligt efter GDPR til Datatilsynet inden 72 timer efter, I bliver bekendt med bruddet.
Rækker det at rotere JWT-nøglerne uden at opdatere?
Nej. Roterer man kun nøglerne, virker eksisterende falske tokens ikke længere, men fejlen i signaturverifikationen består, så en angriber kan skabe en ny falsk token med samme hårdkodede claim-værdi. Opdatering er nødvendig for at lukke selve hullet.
Hvad er den hårdkodede claim-værdi, og hvorfor er det et problem?
Det er en fast, forudsigelig værdi i token-indholdet, som Feast fejlagtigt accepterer som bevis på gyldig identitet uden at kontrollere den kryptografiske signatur. Fordi værdien er statisk og ikke hemmelig i praksis, kan enhver, der kender den, skabe en gyldig-udseende token.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
Feast through 0.66.0 fails to verify JWT token signatures before establishing user identity, allowing attackers to bypass all role-based access control by presenting an unverified token with a hardcoded claim value. Attackers can obtain trusted internal identity and gain unchecked read and write access to all entities, feature views, data sources, and permission policies on the server.
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.