To udmeldinger i juni viste den samme fejl i enterprise‑AI: manglende trust boundaries mellem verden udenfor og de systemer, der har nøglen til alt indeni. Den 15. juni offentliggjorde Varonis SearchLeak, CVE‑2026‑42824, en udnyttelseskæde mod Microsoft 365 Copilot Enterprise Search, der kunne få Copilot til at gennemsøge brugerens postkasse og lække data ud via Bing. Fire dage tidligere beskrev Obsidian Security en tre‑CVE‑kæde mod LiteLLM, hvor en standard lav‑privilegiekonto kunne mint’e en wildcard‑nøgle, blive proxy‑admin og til sidst nå fjernkørsel af kode. To forskellige værktøjer, samme operationelle svaghed, og et konkret problem: eksfiltration uden støj og for stor blast radius.
SearchLeak krævede ingen plugins, ingen ekstra klik, og der var ingen synlig indikator, når eksfiltrationen kørte. Et klik på en tilsyneladende legitim microsoft.com‑adresse kunne være nok. Samtidig er LiteLLM’s gateway designet til at holde mange udbyder‑nøgler bag én proxy, så én fejl kan eksponere alle nøgler. Det gør sagen akut.
Hvorfor det her er akut
SearchLeak rammer Enterprise Search, som arver brugerens fulde organisationsrettigheder, og dermed bliver skadeomfanget per kompromitteret bruger lige så bredt som den brugers adgang. Når et LLM‑drevet søgelag kan starte en legitim intern søgning på baggrund af eksternt input, flytter grænsen mellem internet og intranet sig i praksis ind i modellen. LiteLLM‑kæden viser den anden halvdel af mønsteret: hvis gatewayen både udsteder nøgler og eksekverer værktøjer, bliver den et single point of failure. Det øger risikoen for credential‑eksfiltration, lateral bevægelse og i værste fald fuld kompromittering af downstream‑tjenester.
Teknisk anatomy 1 – SearchLeak
Ifølge Varonis’ disclosure, som er opsummeret af VentureBeat, starter kæden med en microsoft.com‑URL, hvor q‑parameteren smuglertilfører instruktioner til Copilots LLM. Herfra udnyttes en rendering race condition, hvor et billedtag affyres før output‑sanitering er udført. Fordi Bing image‑search‑endpointet er allowlistet i Content Security Policy, kan kæden misbruge det som en SSRF‑kanal til at sende de søgte data ud. Det krævede ingen ekstra brugerinteraktion, og brugeren fik ikke nogen indikator for, at data forlod organisationen.
Microsoft vurderede ifølge Varonis sårbarheden som kritisk og patched den på backenden. VentureBeat bemærker samtidig, at NVD endnu ikke havde givet en score på tidspunktet for rapporteringen, mens en tredjeparts tracker listede 6,5 (medium). Der er uenighed om scoring, men ikke om mekanismen. Pointen er, at Enterprise Search forstørrer skadevolumen, fordi søgningen sker med brugerens egne rettigheder.
Teknisk anatomy 2 – LiteLLM‑kæden
Obsidian Securitys kæde rammer en gateway, der i forvejen har et højt værdiniveau, fordi den typisk holder nøgler til OpenAI, Anthropic, Azure og Amazon Bedrock bag samme proxy. Første led er CVE‑2026‑47101, en autorisationsbypass, der lader en ikke‑admin mint’e en wildcard API‑nøgle. Næste er CVE‑2026‑47102, der via et ubeskyttet \/user\/update forfremmer kaldet til proxy‑admin. Herefter aktiveres CVE‑2026‑40217, hvor et exec()‑hul bryder ud af sandkassen, og kæden ender i fjernkørsel af kode.
VentureBeat refererer Obsidians demonstration af en omvendt shell ved at injicere et forfalsket tool‑call‑response gennem LiteLLMs callback‑mekanisme. LiteLLM var desuden ramt af en separat forsyningskæde‑hændelse tidligere på året, hvor PyPI‑pakker blev backdooret, hvilket understreger gatewayens betydning. En kompromitteret gateway eksponerer alle provider‑credentials, den holder. Det gør segmentering og nøglerotation til førsteprioritet.
Fælles mønster og hvad det betyder
Både VentureBeat og den tekniske brief peger på samme rodårsag: eksterne inputs får lov at flyde ind i interne systemer uden en tydelig trust boundary. Modellen er ikke hovedproblemet her; det er arkitekturen omkring den. Når et web‑klik bliver til en intern søgning, eller når en gateway både udsteder og bruger nøgler uden strenge kontroller, har man allerede rykket forsvarslinjen. Små huller får store konsekvenser.
Operationalt betyder det skærpede krav til input‑validering, rolle‑ og miljøopdeling, og et tydeligt skel mellem det, der må tale til intern søgning, og det, der aldrig må. I praksis kræver det ændringer i både konfiguration, netværk og udvikler‑rutiner. Det koster friktion, men mindre end en tavs eksfiltration, der først opdages via en gammel egress‑graf, ingen kan forklare.
Konsekvenser i praksis
Første og største risiko er credential‑eksfiltration. Når et exfil‑flow kan røre ved tokens eller API‑nøgler, følger resten ofte med, fordi de samme nøgler åbner døre til andre tjenester. Dernæst kommer lateral bevægelse, hvor en angriber bruger de lækkede nøgler til at bevæge sig fra AI‑laget til data‑ eller CI\/CD‑laget. Endelig er der forsyningskæden: LiteLLM har tidligere været ramt af en PyPI‑backdoor, og CISA KEV‑listen har haft relaterede sager med korte frister, hvilket siger noget om tempo og alvor. Compliance‑mæssigt er rapporteringspligten og krav til beviskæder hårde, hvis man ikke allerede har en log, der fanger søgeflows, agent‑callbacks og egress‑mønstre.
Incident‑håndteringen bør antage, at nøgler er set. Det betyder forberedt nøglerotation, tvungen token‑revocation, isolering af gateways og hurtig segmentering af in‑flight trafikken. Uden forberedelse er tidsrummet mellem opdagelse og effektiv inddæmning ofte for langt, og angriberen når at skifte svingdør, før døren er låst.
Fem tjek før frokost
Det her er ikke en pentest‑guide, og der er bevidst ingen PoC‑payloads. Det er fem sikre kontroller, der kan køres hurtigt for at bekræfte eksponerede flader og manglende grænser. Hver kontrol svarer til en mekanisme i disclosure‑materialet og afdækker konfigurations‑ og driftsfejl, ikke bare kodefejl. Flere kan køres af netværk eller SecOps uden at vente på udviklingsteamet.
- CSP og egress‑allowlist sanity check: Hent den aktive Content‑Security‑Policy fra jeres Copilot‑relaterede domæner og kontroller, om tredjeparts søge‑ eller billedendpoints er unødigt allowlistet. Eksempel: curl -sI https:\/\/[app‑host]\/ | grep -i content-security-policy. Verificer samtidig, at egress‑firewall eller proxy logger og begrænser kald til billed‑ og søgeendpoints, der kan fungere som SSRF‑kanaler.
- Enterprise Search‑connector permissions: Udtræk effektive rettigheder for de konti, der bruges til Enterprise Search‑connectorer, og bekræft mindst mulige privilegier. Eksempel i PowerShell for M365: Get-EXOServicePrincipal | Select-Object DisplayName,AppId; og gennemgå derefter App Registrations for API‑tilladelser samt Conditional Access‑politikker, der segmenterer søgning fra generel adgang.
- LiteLLM admin‑surface review: Kortlæg alle offentligt tilgængelige LiteLLM‑endpoints og bekræft auth‑krav for nøgleudstedelse og brugeropdatering. Eksempel: curl -i https:\/\/[litellm‑host]\/v1\/keys og curl -i -X POST https:\/\/[litellm‑host]\/user\/update med tom auth for at sikre 401\/403. Tjek også, at callback‑URL’er kun peger til interne, godkendte værter, og at webhooks kræver signaturvalidering.
- Secrets‑segmentering og miljøopdeling: Gennemgå, om gatewayen holder cross‑provider nøgler i samme løbeværk uden tenant‑ eller miljøadskillelse. Hurtig test: forsøg et tørt kald med en nøgle fra miljø A mod en modelkonfiguration i miljø B og bekræft, at det fejler. Hvis det lykkes, er grænsen porøs, og rotation bør planlægges straks.
- Audit‑log‑synlighed for søgning og agent‑callbacks: Kør en søgning fra en testkonto og verificer, at der findes korrelerbare hændelser i både applikationslog, proxy\/egress‑log og identitetslog. Sæt en SIEM‑regel: varsel på udgående kald til image‑ og søgedomæner uden for den normale liste samt usædvanlige opkald fra LiteLLM‑værten til eksterne IP’er.
Hvis to af fem ovenfor fejler, er der typisk en arkitekturændring i vente. Det kan være at skille nøgleudstedelse fra gatewayens runtime, at flytte allowlists fra applikation til netværk, eller at lade Enterprise Search køre på egne servicekonti uden bred arv af brugerens rettigheder. Sæt en kort deadline, og lad det ikke drukne i backloggen.
Implementering, prioritering og tradeoffs
Det akutte er at fjerne stille eksfiltrationsveje og begrænse blast radius. Det betyder: stram CSP og egress‑kontrol, fjern wildcard‑nøgler, slå signaturkrav til på callbacks og isoler gatewayens runtime fra nøgle‑minting. Vigtigt men sekundært er forbedret prompt‑filtrering og query‑isolation i Copilot‑lag, som typisk kræver mere udviklingstid og test. Det, der kræver analyse, er dybere RBAC‑ændringer og per‑tenant nøgler i komplekse miljøer, fordi det påvirker deployments, CI\/CD og driftsprocesser bredt.
Kommunikation til ledelsen
Når alvoren skal forklares: Microsoft har ifølge Varonis klassificeret SearchLeak som kritisk og patchet backend; NVD‑scoren var ikke på plads ved rapporteringstidspunktet, og en tredjepart listede 6,5, hvilket mest viser uenighed i scoring, ikke i mekanisme. For LiteLLM ligger flere CVE’er tæt i tid, og der har været en separat KEV‑markeret sag. Det er dokumenteret nok til at handle på nu og konkret nok til at måle på bagefter.
Hvad du bør kræve af leverandører
Start med patch‑verifikation, ikke bare patch‑meddelelser. Bed om dokumentation for, hvilke builds der indeholder hvilke CVE‑fixes, og test i staging med negative reproduktioner, så du ser, at kendte veje er lukkede. Spørg, om ændringen ligger i backend, klient eller gateway, og hvem der bærer ansvaret for egress‑allowlists og callback‑signering. For gateways: spørg, om nøgleudstedelse er fysisk eller logisk adskilt fra runtime, og om der findes indbygget support for per‑tenant eller per‑service nøgler.
For SaaS‑søgefunktioner: spørg til input‑sanitering, prompt‑filtering og mekanismer mod rendering race conditions. For on‑prem og selvhostede dele: bed om hardening‑guides, og om standardkonfigurationer stadig åbner endpoints, der ikke bør eksponeres. Standarder ender ofte i drift, når tiden er knap.
Usikkerheder og huller i rapporteringen
Der mangler stadig et fuldt, offentligt teknisk advisory fra Microsoft, der detaljerer, hvordan backend‑patchen for SearchLeak lukker hele kæden, og hvilke klienter der var påvirket. NVD‑score for SearchLeak var ikke publiceret i de tilgængelige kilder ved skrivende stund, og medier refererer en enkelt tredjeparts score på 6,5, som ikke er endelig. Der er heller ikke fremvist veldokumenterede eksempler på udnyttelse i det fri i de åbne kilder. Det gør telemetri fra MDR og bredere scanninger værdifulde de næste uger.
Konklusion og næste skridt
Hvis tiden er knap i dag, så gør tre ting: stram CSP\/egress nu, segmenter nøgler i gatewayen, og slå signaturkrav til på callbacks. Planlæg derefter en kort change‑window til at adskille nøgleudstedelse fra runtime og fjerne unødige Enterprise Search‑tilladelser. Integrer de fem tjek i faste driftstjek og i incident‑playbooks, så negative tests bliver standard og ikke særtilfælde.
