CVE-2026-8476: Kritisk RCE i IBM Langflow OSS
IBM Langflow OSS versionerne 1.0.0 til 1.10.0 har en kritisk fejl, der giver fjernstyret kodekørsel. Opdatér eller afskærm systemet nu.
Hvad er det?
CVE-2026-8476 er en kritisk sårbarhed i IBM Langflow OSS, et lav-kode værktøj til at bygge AI- og sprogmodel-arbejdsgange. Fejlen ligger i den disk-baserede cache-funktion, hvor klassen AsyncDiskCache bruger Pythons pickle.loads() til at genskabe gemte objekter fra disk. Denne funktion udfører kode uden at kontrollere, om dataene er ægte eller ufarlige. Det betyder, at en fil eller besked, der ligner et gyldigt cache-objekt, i virkeligheden kan indeholde et program, som køres automatisk, når systemet læser den. Angribere, der på nogen måde kan påvirke, hvad der bliver cachet, gennem filsystemadgang, ondsindede input i arbejdsgange, brugerdefinerede komponenter eller manipulation af API’et, kan få fuld kontrol over serveren med de rettigheder, Langflow-processen har.
Hvem rammer det?
Sårbarheden findes i IBM Langflow OSS version 1.0.0 til og med 1.10.0. Det rammer virksomheder og kommuner, der selv hoster Langflow til at bygge interne AI-løsninger, chatbots eller automatiserede arbejdsgange, både i test og i produktion. Alle installationer, der bruger den disk-baserede cache-funktion, er berørt, uanset om Langflow kører på en lokal server, i en container eller i skyen.
Hvad kan ske?
En angriber med selv lav adgang, for eksempel en almindelig API-nøgle eller adgang til en arbejdsgang, kan lægge et forberedt cache-objekt ind i systemet. Når Langflow senere læser det fra disk, kører den medfølgende kode automatisk med serverens rettigheder. I praksis betyder det, at angriberen kan overtage serveren, stjæle data, installere skadelig kode eller bruge serveren som springbræt til resten af netværket. Ligger Langflow-serveren sammen med andre interne systemer, kan konsekvensen sprede sig langt ud over selve AI-værktøjet.
Hvor alvorligt er det?
CVSS-scoren er 9,9 af 10, hvilket er den højeste alvorlighedsgrad. Angrebet kræver kun lav adgang, for eksempel en gyldig API-nøgle eller brugerkonto med begrænsede rettigheder, og ingen handling fra en bruger. Det kan udføres over netværket, og fordi angrebet ændrer omfang (scope changed), kan det påvirke ressourcer uden for selve Langflow-komponenten. Der er på offentliggørelsestidspunktet ingen oplysninger om, at sårbarheden er udnyttet i praksis, men fremgangsmåden er velbeskrevet og teknisk enkel at udføre for en person med kendskab til Python-deserialisering.
Hvad gør jeg nu?
Følgende punkter lukker hullet og begrænser skaden, mens I venter på en officiel rettelse.
- Opdatér Langflow til en version, hvor cache-mekanismen er rettet, eller deaktivér den disk-baserede cache-funktion midlertidigt, hvis jeres opsætning tillader det.
- Begræns netværksadgang til Langflow-serveren og dens API, så kun betroede interne systemer og medarbejdere kan tilgå den.
- Gennemgå og udskift API-nøgler og brugerkonti med lav adgang, som kan have været eksponeret eller delt bredt.
- Gennemgå logs for uventede fejl i deserialisering eller processer, der er startet af Langflow, og se efter tegn på uautoriseret adgang.
- Placér Langflow-serveren i et separat netværkssegment, så en eventuel kompromittering ikke automatisk giver adgang til øvrige systemer.
- Kontakt en sikkerhedsrådgiver, hvis I ikke selv kan afklare, om jeres installation er sårbar, eller om den allerede er blevet misbrugt.
Opdatér inden for 48 timer
Vi anbefaler, at I straks kortlægger, om Langflow OSS kører i jeres miljø, og hvilken version. Er I på en sårbar version, bør I deaktivere den disk-baserede cache og afskærme systemet fra internettet, indtil en rettet version er installeret. Det er kun forsvarligt at vente, hvis Langflow-serveren allerede er fuldt isoleret fra internettet og øvrige interne systemer, og der ikke findes lav-privilegerede API-nøgler, som eksterne kan få adgang til.
Tidslinje
Konkrete eksempler
Lækket API-nøgle giver fuld serverovertagelse
En dansk virksomhed bruger Langflow OSS til at bygge en intern AI-chatbot til kundeservice. En udvikler har delt en lav-privilegeret API-nøgle i et internt dokument, som senere lækkes. En angriber bruger nøglen til at sende et forberedt cache-objekt til systemet, som udløser skadelig kode, når Langflow læser det fra disk. Angriberen får dermed adgang til serveren med samme rettigheder som Langflow-processen og kan derfra bevæge sig videre i virksomhedens netværk.
Ofte stillede spørgsmål
Hvordan finder vi ud af, om vi bruger den sårbare version af Langflow?
Tjek versionsnummeret i jeres Langflow-installation, enten i administrationspanelet eller via kommandoen, der viser den installerede pakkeversion. Er tallet mellem 1.0.0 og 1.10.0, er I berørt.
Kan vi vente til efter weekenden med at handle?
Det kan I kun, hvis Langflow-serveren allerede er isoleret fra internettet og ikke deler netværk med andre kritiske systemer. Er serveren tilgængelig udefra eller deler netværk med andre interne systemer, bør I handle inden for et par timer, ikke dage.
Er sårbarheden udnyttet, som vi kender til?
På offentliggørelsestidspunktet er der ingen kendte rapporter om, at sårbarheden er blevet udnyttet i praksis. Det tekniske grundlag for et angreb er dog enkelt at udføre, så det bør ikke tolkes som lav risiko.
Skal vi anmelde dette som en sikkerhedshændelse?
Kun hvis I finder tegn på, at sårbarheden faktisk er blevet udnyttet, og persondata eller kritiske systemer er blevet berørt. Ren opdatering af et sårbart system uden tegn på misbrug kræver normalt ikke anmeldelse.
Hvad gør vi, hvis vi ikke kan opdatere Langflow lige nu?
Deaktivér den disk-baserede cache-funktion, hvis det er muligt i jeres opsætning, og luk al ekstern netværksadgang til Langflow, indtil I kan installere en rettet version.
Påvirker sårbarheden andre systemer, der er forbundet med Langflow?
Ja, fordi angrebet ændrer omfang (scope changed), kan en kompromitteret Langflow-server give angriberen adgang til andre ressourcer, som serveren har rettigheder til, ikke kun Langflow selv.
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)
IBM Langflow OSS 1.0.0 through 1.10.0 contain a critical remote code execution vulnerability in the disk-based caching mechanism. The AsyncDiskCache class uses Python’s unsafe pickle.loads() function to deserialize cached objects from disk without validation, integrity verification, or authentication, enabling arbitrary code execution when malicious pickle payloads are processed. Attackers who can influence cached data through file system access, malicious workflow inputs, custom components, or API manipulation can achieve complete system compromise with the privileges of the Langflow server process.
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.