CVE-2026-76850: Kritisk sårbarhed i LMDeploy
Kritisk sårbarhed i LMDeploy giver angribere mulighed for at køre vilkårlig kode på din AI-server uden login.
Hvad er det?
LMDeploy er et open source-værktøj til at afvikle store sprogmodeller (AI-modeller som fx ChatGPT-lignende systemer) i produktion. Sårbarheden ligger i den måde, systemet udveksler data mellem interne servere på, når man bruger den såkaldte disaggregated serving-funktion (en opsætning hvor AI-modellen er fordelt på flere maskiner).
Problemet er, at systemet bruger en usikker metode kaldet pickle-deserialisering (en måde at pakke og udpakke data på i Python, der er known for at være farlig) til at modtage beskeder fra andre servere — og det gør det uden at tjekke, hvem afsenderen er, før dataene allerede er udpakket og kørt.
Hvem rammer det?
Sårbarheden rammer dig, hvis din virksomhed:
- Selv hoster LMDeploy til at drive AI-modeller (fx interne chatbots, dokumentanalyse eller lignende)
- Har aktiveret disaggregated serving-funktionen (fordeling af AI-modellen på flere maskiner)
- Ikke har sat API-nøgler op til at beskytte adgang til serveren
Bruger du LMDeploy uden disaggregated serving, eller tilgår du en ekstern AI-tjeneste du ikke selv drifter, er du ikke direkte berørt.
Hvad kan ske?
En angriber, der kan nå din LMDeploy-server over netværket, kan sende en specialfremstillet besked, der får serveren til at hente og udføre ondsindet kode — helt uden at skulle logge ind.
Det kan betyde:
- Fuld kontrol over serverprocessen — angriberen kan gøre, hvad som helst på den maskine, AI-modellen kører på
- Datatyveri — adgang til de data, modellen behandler, herunder evt. fortrolige dokumenter eller kundeoplysninger
- Ransomware eller sabotage — serveren kan krypteres, slettes eller bruges som springbræt ind i resten af netværket
Hvor alvorligt er det?
CVSS-scoren er 9.8 ud af 10 (Kritisk). Det er næsten det højeste mulige niveau. Angrebsvektoren er:
- Over netværket — angriberen behøver ikke fysisk adgang
- Lav kompleksitet — angrebet kræver ingen særlig teknisk ekspertise
- Ingen login nødvendigt — som standard er endpoints ubeskyttede
- Ingen brugerinteraktion — offeret behøver ikke klikke på noget
Kombinationen af disse faktorer gør sårbarheden ekstremt let at udnytte og potentielt katastrofal for berørte systemer.
Hvad gør jeg nu?
Følg disse trin i prioriteret rækkefølge:
- Find ud af, om du er berørt: Tjek om din LMDeploy-installation bruger disaggregated serving. Kig i din konfiguration efter parametrene
p2p_initializeellerp2p_connect— er de aktive, er du i risiko. - Opdatér LMDeploy straks: Tjek om der er udgivet en patchet version og opdatér med det samme. Se projektets officielle GitHub-repository for den nyeste version.
- Aktiver API-nøgler: Hvis du ikke kan opdatere med det samme, så sæt
api_keys-parameteren til en stærk nøgle i din server-konfiguration. Det lukker for ubeskyttet adgang til de sårbare endpoints. - Begræns netværksadgang: Sørg for at LMDeploy-serveren ikke er tilgængelig fra internettet. Brug firewall-regler til kun at tillade adgang fra kendte interne IP-adresser.
- Overvåg for mistænkelig aktivitet: Gennemgå server-logfiler for usædvanlige forbindelser til ZMQ-porte eller uventede processer startet af AI-serveren.
Handl inden for 24 timer
Denne sårbarhed er kritisk og bør behandles som en akut hændelse. Hvis du selv driver LMDeploy med disaggregated serving, skal du øjeblikkeligt enten lukke ekstern adgang til serveren via firewall eller aktivere API-nøglebeskyttelse — selv inden en officiel patch er klar. Kontakt os gerne for hjælp til at vurdere din eksponering og implementere hurtige beskyttelsesforanstaltninger.
Tidslinje
Konkrete eksempler
Angriberen overtager AI-serveren via åbent endpoint
En angriber scanner internettet og finder en LMDeploy-server med aktiveret disaggregated serving og ingen API-nøgler. Han sender en HTTP POST-forespørgsel til /distserve/p2p_connect med adressen på sin egen server som ZMQ-endpoint. LMDeploy-serveren opretter forbindelse og henter angribers ondsindede pickle-data, som automatisk køres — og angriberen har nu fuld kontrol over AI-serverens operativsystem.
Datatyveri af fortrolige dokumenter behandlet af AI-modellen
En virksomhed bruger LMDeploy til at analysere fortrolige juridiske kontrakter internt. En angriber udnytter sårbarheden til at køre kode på serveren, der kopierer alle dokumenter, der er blevet behandlet af modellen, og sender dem til en ekstern server. Virksomheden opdager det ikke, fordi der ikke er sat alarmering op på usædvanlig netværkstrafik.
AI-serveren bruges som springbræt ind i virksomhedens interne netværk
Angriberen overtager LMDeploy-serveren og bruger den som udgangspunkt for at kortlægge og angribe andre systemer på virksomhedens interne netværk — fx filservere, databaser eller Active Directory (det system der styrer brugerlogins). Fordi serveren er intern og ‘stolet’, vækker den ikke samme mistanke som en udefrakommende forbindelse.
Ofte stillede spørgsmål
Hvad er pickle-deserialisering, og hvorfor er det farligt?
Pickle er en Python-funktion til at gemme og genskabe data. Problemet er, at pickle kan udføre programkode, når data pakkes ud. Hvis en angriber kan sende sine egne pickle-data til din server, kan han få serveren til at køre netop den kode, han ønsker — det er ligesom at åbne en ukendt vedhæftet fil og lade den gøre, hvad den vil.
Er jeg i fare, selvom min LMDeploy-server ikke er eksponeret mod internettet?
Risikoen er markant lavere, hvis serveren kun er tilgængelig internt. Men er der andre kompromitterede systemer på dit netværk, eller er adgangen ikke stramt styret, kan en intern angriber stadig udnytte sårbarheden. Derfor bør du stadig opdatere og aktivere API-nøgler, selv i lukkede miljøer.
Hvad er 'disaggregated serving', og ved jeg om jeg bruger det?
Disaggregated serving betyder, at AI-modellen er fordelt på flere servere, der kommunikerer med hinanden. Det er typisk en bevidst, avanceret opsætning. Er du usikker, kan du spørge den person, der opsatte dit AI-system — eller se i konfigurationsfilerne efter ord som p2p_connect, p2p_initialize eller distserve. Finder du dem ikke, er du sandsynligvis ikke berørt.
Hvornår kommer der en officiel rettelse (patch)?
På nuværende tidspunkt er der ikke bekræftet en officiel patch. Hold øje med LMDeploys officielle GitHub-repository og sikkerhedsmeddelelser. Aktivér i mellemtiden API-nøglebeskyttelse og begræns netværksadgang som midlertidige tiltag.
Kan min AI-model eller data være blevet stjålet, uden at jeg ved det?
Desværre er det muligt. Angreb via denne sårbarhed efterlader ikke nødvendigvis synlige spor. Bruger du LMDeploy med disaggregated serving og uden API-nøgler, bør du gennemgå server-logfiler grundigt og overveje at få en sikkerhedsekspert til at undersøge systemet for tegn på kompromittering.
Ramte produkter
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)
LMDeploy deserializes disaggregated-serving peer messages with pickle. The handle_zmq_recv coroutine in lmdeploy/pytorch/disagg/conn/engine_conn.py reads peer-to-peer cache-free requests with recv_pyobj(), which deserializes the received bytes with pickle.loads(), and the isinstance check against DistServeCacheFreeRequest runs only after deserialization has already completed. The peer that supplies those bytes is caller-controlled: p2p_connect passes remote_engine_endpoint_info.zmq_address from the request body to connect() on the ZMQ PULL socket, and the POST /distserve/p2p_initialize and /distserve/p2p_connect endpoints in lmdeploy/serve/openai/api_server.py apply no authentication unless the server is started with api_keys, which defaults to None. A remote attacker can direct an engine to pull from a ZMQ endpoint under their control and execute arbitrary code in the engine process. Deployments that do not enable disaggregated serving are not affected, because the receive loop is only started once the migration backend accepts the connection.
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.