AI-sikkerhedsaudit: Copilot, LiteLLM CVE

Sårbarheden, der er blevet døbt SearchLeak og registreret som CVE-2026-42824, ramte Copilots søgeintegration mod Outlook og andre Microsoft 365-tjenester. Mekanikken var konkret: en angriber kunne udforme en URL, der så ud til at høre hjemme på microsoft.com, og som Copilots Enterprise Search derfor implicit stolede på som førstepartstrafik. Den URL sendte kaldet videre gennem Bing, og fordi Bing-integrationen ikke skelnede mellem legitime interne kald og et kald, angriberen selv havde konstrueret, opstod en klassisk SSRF, en server-side request forgery, hvor Copilots egen søgetjeneste blev narret til at hente data på angriberens vegne i stedet for brugerens.

Det er den vej, postkassedata endte med at kunne eksfiltreres uden at brugeren selv havde bedt om det. Søgefunktionen validerede ikke konsekvent, om den aktuelle bruger reelt havde adgang til de data, den serverede, og SSRF-hoppet gennem Bing gjorde det muligt at omgå den kontrol helt.

Det er ikke en avanceret angrebsteknik i sin kerne. Det er en klassisk adgangskontrolfejl kombineret med en klassisk SSRF, blot flyttet ind i et AI-lag, hvor den er sværere at få øje på, fordi den gemmer sig bag en naturlig sprog-forespørgsel i stedet for en direkte API-kaldsstruktur. Det centrale problem er ikke, at Copilot kan søge bredt. Det er, at søgefunktionen fik lov at operere med implicit tillid til, at alt input, inklusive en craftet microsoft.com-URL, var legitimt, uden at nogen lagde en streng grænse mellem "det brugeren beder om" og "det brugeren faktisk må se".

LiteLLM er en udbredt proxy, der bruges til at styre og rute kald til forskellige AI-modeller, og den sidder derfor ofte centralt i virksomheders AI-infrastruktur, mellem applikationslaget og selve modelleverandørerne. Det gør enhver sårbarhed i LiteLLM særligt alvorlig, fordi et brud der ikke bare rammer én applikation, men potentielt hele modeltrafikken.

Den kritiske CVE-kæde, der blev afdækket i perioden, viste en vej fra en almindelig, lavt privilegeret brugerkonto til fuld administratoradgang på selve proxyen. Kæden bestod af tre separate CVE'er og blev til sidst vurderet til CVSS 9.9, den øverste ende af skalaen, fordi den samlede sig i remote code execution på selve gateway-laget. Jeg har ikke et bekræftet CVE-nummer for hver af de tre sårbarheder at citere her, så jeg lader være med at gætte. Det, jeg kan sige med sikkerhed, er hvad kæden ramte: mangelfuld validering af inputparametre kombineret med en autorisationsfejl, der lod en bruger eskalere sine egne rettigheder inden for systemet, uden at nogen mellemliggende kontrol greb ind.

Det, der gør denne type sårbarhed farlig i praksis, er ikke kompleksiteten i selve angrebet, det er hvor meget der ligger bag den ene proxy. Får en angriber administratoradgang til LiteLLM, kan de potentielt omdirigere trafik, læse API-nøgler til underliggende modelleverandører, eller injicere egne instruktioner i forespørgsler, der passerer igennem. En enkelt sårbarhed i infrastrukturlaget bliver dermed en indgang til alt, der er koblet på.

Der parallelle mønster dukkede op i Langflow-miljøer og i den bredere kampagne, der er blevet omtalt som Mini Shai-Hulud. Her var problemet ikke en enkelt kodefejl, men en strukturel svaghed: AI-agenter og workflow-byggeklodser, der automatisk arvede rettigheder fra det miljø, de blev kørt i, uden at nogen eksplicit havde taget stilling til, om agenten reelt skulle have adgang til de ressourcer.

En agent bygget til at hente data fra en database endte i praksis med adgang til langt mere, fordi den kørte under en servicekonto med brede rettigheder, som ingen havde strammet til det specifikke formål. Det er den samme grundfejl som i SearchLeak og LiteLLM-sagen, blot flyttet endnu et niveau ud, til selve orkestreringslaget, hvor agenter kæder værktøjer og datakilder sammen. Det er præcis den udfordring, hvor AI-agenter der arver rettigheder fra deres miljø skal håndteres eksplicit, ikke implicit.

Mønsteret på tværs af de tre hændelser er konsistent: ingen af sårbarhederne krævede et sofistikeret nul-dages angreb. De udnyttede alle det samme underliggende designvalg, at et system, der kan handle bredt, fik lov at handle bredt, uden en eksplicit, håndhævet grænse for hvad det faktisk måtte.

Vi arbejder med at hjælpe virksomheder gennem netop den slags gennemgange, og den følgende liste er de fem punkter, vi selv starter med, når vi går et AI-stack igennem.

**1. Kortlæg hvad hvert AI-værktøj rent faktisk kan tilgå.** Ikke hvad det er designet til at bruge, men hvad det tekniske set kan nå gennem de rettigheder, det kører under. Gå servicekonti og API-nøgler igennem enkeltvis.

**2. Tjek om søgefunktioner og RAG-pipelines validerer adgang per forespørgsel, og om de kan narres af interne URL'er.** Hvis en søgefunktion returnerer resultater uden at genbekræfte, at den aktuelle bruger har ret til at se dem, eller uden at afvise en konstrueret intern URL som den, der udnyttede SearchLeak, har I samme klasse af problem.

**3. Gennemgå jeres proxy- og gateway-lag for privilegie-eskalering, med konkrete kommandoer.** Kør `pip show litellm` eller `litellm --version` for at få den installerede version, og hold den op mod LiteLLM's egne security-advisories på GitHub. Gennemgå derefter `general_settings` og `router_settings` i jeres `config.yaml`, eller kald admin-endpointet `/user/info`, og bekræft eksplicit, at almindelige brugerroller ikke kan nå `proxy_admin`-scope.

**4. Kortlæg agentkæder og deres nedarvede rettigheder.** Enhver agent, der kan udføre flere trin i træk, bør have sit eget begrænsede sæt af rettigheder, ikke arve dem fra miljøet, den kører i.

**5. Indfør eksplicitte tillidsgrænser mellem input og handling.** Det gennemgående svigt i alle fire sager var, at systemet behandlede brugerinput og systemhandling som samme tillidsniveau. Byg et lag ind, der eksplicit spørger: har denne konkrete forespørgsel ret til denne konkrete handling, hver gang.

De fem trin kræver ikke et nyt system eller en stor ombygning. De kræver, at nogen faktisk sætter sig ned og går rettighedsstrukturen igennem punkt for punkt, hvilket i praksis er den øvelse, mange virksomheder skubber foran sig, fordi den ikke føles akut, før den bliver det.

De fire hændelser er ikke enkeltstående uheld. De er symptomer på, at AI-værktøjer generelt bliver rullet ud hurtigere, end tillidsmodellen omkring dem bliver bygget færdig. Det gælder søgefunktioner, det gælder proxyer, det gælder agentkæder, og det gælder forsyningskæden bag værktøjerne, uanset om de kommer fra en stor leverandør som Microsoft eller fra open source-projekter som LiteLLM og Langflow.

Jeg er principal konsulent hos AI Enterprise Konsulenten, hvor jeg sammen med et team driver større AI-projekter for danske virksomheder, fra problemafklaring og planlægning til implementering og drift, og den erfaring peger konsekvent på det samme: de virksomheder, der undgår den slags hændelser, er dem, der bygger tillidsgrænser ind fra starten, ikke dem, der patcher dem ind bagefter.

Den gode nyhed er, at femtrins-auditen ovenfor kan gennemføres på en dag eller to for de fleste mellemstore stacks. Den dårlige nyhed er, at hvis I ikke allerede har gjort det, er I sandsynligvis eksponeret på mindst et af de fem punkter lige nu.