LiteLLM beskriver full angrepskjede: lekket hovednøkkel, token uten avgrensning og avslappet godkjenning

LiteLLM beskriver full angrepskjede: lekket hovednøkkel, token uten avgrensning og avslappet godkjenning

LiteLLM publiserte 24. oktober en revidert rotårsak for angrepet mot utgivelsesrørledningen: En hovednøkkel for Agent Platform ble ved et uhell sjekket inn i et offentlig GitHub-repo 27. mai 2026, og ble aldri trukket tilbake. Ifølge selskapet var det denne nøkkelen som ga angriperen inngangen til å forgifte versjon 1.107.0 av den populære Python-pakken 21. oktober – en rekonstruksjon som skiller seg fra selskapets tidligere peking på lekkede Claude Code-logger, uten at de to forklaringene er forent. For brukere som fortsatt rydder opp, endrer den korrigerte kjeden ikke hva de må gjøre, men den viser hvilke tre kontrollfeil som gjorde angrepet mulig.

Starten: en nøkkel publisert i mai, aldri trukket tilbake

LiteLLMs Oliver Jensen og Mateo Wang beskriver i den oppdaterte etterforskningen hvordan en konfigurasjonsfil ble sjekket inn i det offentlige depotet LiteLLM-Labs/lite-harness 27. mai 2026. Filen inneholdt hovednøkkelen til en distribusjon av LiteLLM Agent Platform, et verktøy selskapet bruker til å orkestrere agenter.

Feilen ble raskt oppdaget, og committen ble force-pusht bort. Ifølge Jensen og Wang identifiserte de selv de eksponerte nøklene som behov for tilbaketrekking – men tilbaketrekkingen ble aldri utført for hovednøkkelen. Dette er selskapets egen fremstilling, gjengitt av The Hacker News (The Hacker News, sitat oversatt fra engelsk).

I mai la altså selskapet merke til problemet. I mer enn fire måneder lå nøkkelen tilgjengelig for alle som hadde kopiert den fra repo-historikken.

10. oktober: eier-nivå tilgang og tokens stjålet fra CI

Ifølge LiteLLM brukte en ukjent angriper, opererende fra IP-adressen 69.48.229[.]143, den urevokerte nøkkelen 10. oktober 2026 til å få tilgang til Agent Platform. Der hentet angriperen ut en GitHub CLI OAuth-token som plattformen var konfigurert med for å la selvhostede skyagenter opprette pull requests mot GitHub-depoter. Tokenen var, ifølge selskapet, ikke avgrenset i omfang, og var knyttet til selskapets GitHub-konto for organisasjonseier.

Samme kveld, mellom 22:11 og 22:12 UTC, sjekket angriperen ifølge tidslinjen inn ondsinnede arbeidsflyter i depotene BerriAI/litellm og BerriAI/litellm-auto. Målet var å skaffe GitHub CLI OAuth-tokens tilknyttet to ingeniører med vedlikeholdsrettigheter, ved å sende dem til et angriperstyrt endepunkt på webhook[.]site. Begge kjøringene ble slettet i løpet av minutter.

Socket har gravd ut to ondsinnede committer som la til en arbeidsflyt i .github/workflows/cache.yml, 10. og 12. oktober. Sikkerhetsforsker Karlo Zanki i Socket forklarer at ingen av committene ble pushet til en gren som fortsatt finnes, men til kortlivede grener kalt ci-tmp- som ble «opprettet, brukt og slettet i løpet av minutter», og at dette er grunnen til at aktiviteten «etterlater nesten ingenting i depotets vanlige historikk» (The Hacker News, sitat oversatt fra engelsk).

Dette forklarer hvorfor angrepet ikke var synlig i vanlig depothistorikk: det foregikk i grener som aldri ble stående.

21. oktober: avslappet godkjenning, en bindestrek og tre timer på PyPI

De stjålne tokens lå i ro til 21. oktober. Mellom 10:08 og 11:08 UTC, ifølge LiteLLMs tidslinje, ble grenbeskyttelsen overstyrt, og utgivelsespipelinen ble vist mot et dobbeltgjenger-depot: «Berri-AI/litellm» med bindestrek, i stedet for det ekte «BerriAI/litellm». Én feilplassert bindestrek skilte det ondsinnede kildedepotet fra det legitime.

Her spiller den tredje kontrollfeilen inn. LiteLLM forklarer at utgivelser normalt krever at en autorisert ingeniør starter bygget, og at det godkjennes av «en spesiell konto låst til en fysisk enhet på kontoret vårt». Ifølge selskapet var denne regelen lempet tidligere den uken, for å ta høyde for et midlertidig press for hyppigere utgivelser og tilbakeporteringer, slik at to vilkårlige ingeniører kunne starte og godkjenne en utgivelse. Angriperen brukte dermed ifølge LiteLLM én av tokenene til å starte utgivelsen, etter å ha vist deployeren mot sitt ondsinnede depot, og en annen til å godkjenne den (The Hacker News, sitat oversatt fra engelsk).

Versjon 1.107.0 ble publisert til PyPI 21. oktober mellom 11:39 og 11:40 UTC, og til Docker Hub og GHCR kl. 11:46. Upwind-forsker Lidor Machluf rapporterte den ondsinnede pakken kl. 12:06. PyPI satte versjonen i karantene kl. 13:23, mens Docker ifølge Help Net Security fortsatte å servere det ondsinnede bygget til kl. 14:20 (Help Net Security).

I løpet av de rundt tre timene pakkene var tilgjengelige, ble de lastet ned over 49 000 ganger, ifølge SecurityWeek med henvisning til estimater fra LiteLLM og ClickPy (SecurityWeek). For et bibliotek som Socket anslår har rundt 23 millioner nedlastinger per uke, og som typisk kjører med leverandør-API-nøkler, skyidentiteter og databasetilkoblingsstrenger i nærheten, er det en betydelig eksponering (Help Net Security).

Hva skadevaren faktisk gjorde

Ifølge Wiz inneholdt pakken kompilert skadevare med dobbel funksjon: en legitimasjonstyv og et verktøy for ekstern tilgang. Wiz-forskerne Benjamin Read og Rami McCarthy beskriver en persistensteknikk de ikke har sett dokumentert i vill tilstand før: skadevaren brukte både .pth-filer (cook.pth/cook.py, som eksfiltrerte data til litellm[.]dev/healthcheck) og sitecustomize.py (som hentet et C2-domene fra en GitHub dead drop) samtidig.

«Tilnærmingen med to teknikker, ved å bruke både .pth-filer og sitecustomize.py samtidig, ser ut til å være det første dokumenterte tilfellet i vill tilstand,» skriver Read og McCarthy (oversatt fra engelsk) (The Hacker News).

Wiz har også sett de stjålne legitimasjonene i bruk. Omtrent fire og en halv time etter at dataene forlot ofrenes systemer, begynte angriperen å validere AWS-legitimasjon hentet fra kompromitterte CI-runners og Kubernetes-noder, og sjekket om de kunne nå AI-modeller på Amazon Bedrock – aktivitet Wiz knytter til LLMjacking, altså misbruk av stjålne sky-legitimasjoner til å kjøre AI-arbeidsmengder på offerets regning (Help Net Security).

Wiz angir at den siste rene versjonen var 1.106.2. LiteLLM sier at kunder som bruker selskapets private depot for enterprise-utgivelser, ikke ble berørt (SecurityWeek).

Revisjonen: to forklaringer som ikke er forent

Den nye fremstillingen skiller seg vesentlig fra selskapets opprinnelige rapport etter 21. oktober. Den gang skrev LiteLLM at de trodde angriperen hadde fått tilgang til en intern distribusjon eksponert mot internett, hentet GitHub CLI OAuth-tokens fra Claude Code-svar logget der, og brukt disse legitimasjonene til å kompromittere utgivelsesarbeidsflyten (TNW). Angrepet involverte ifølge den rapporten tre utvikleres legitimasjon: én til å slå av grenbeskyttelse, én til å godkjenne utgivelsen, og én til å slette spor.

Den oppdaterte versjonen plasserer inngangen ved den urevokerte hovednøkkelen og token-tyveri via CI-arbeidsflyter. Kildene i dette grunnlaget forener ikke de to forklaringene, og det er uklart om hovednøkkelforklaringen skal erstatte eller utfylle Claude Code-teorien – for eksempel var det tidligere ubekreftet hvordan angriperen i første omgang nådde den interne distribusjonen. Lesere bør derfor forholde seg til begge beskrivelsene som selskapets egne, tildels uavklarte rekonstruksjoner, ikke som dokumenterte fakta.

Tre kontrollfeiler – og hva brukere fortsatt må gjøre

Det praktiske læringspunktet ligger i de tre feilene LiteLLM selv navngir i sin rekonstruksjon:

1. Lekkede nøkler må faktisk trekkes tilbake. Selskapet identifiserte hovednøkkelen som behov for tilbaketrekking i mai – og utførte det aldri. Å force-pushe en commit bort fjerner ikke nøkkelen fra alle som allerede har kopiert den.
2. Token-omfang betyr noe. En GitHub CLI OAuth-token som ikke var avgrenset i omfang, og som var knyttet til organisasjonseier-kontoen, ga angriperen vei videre til depotene.
3. Midlertidig avslapping av utgivelseskontroller er et angrepsvindu. Regelen om én autorisert utløser og én enhetslåst godkjenner ble erstattet av at to vilkårlige ingeniører kunne starte og godkjenne utgivelser – akkurat den uken angriperen slo til.

For brukere er rådene uendret av den reviderte årsaken: Sjekk om du har installert 1.107.0, og behandl eventuelle installasjoner av den versjonen som kompromitterte. Roter alle legitimasjoner som kan ha vært eksponert, inkludert AWS-nøkler fra CI-miljøer. Wiz angir 1.106.2 som siste rene versjon.

Flere spørsmål står fortsatt åpent: Det er ikke kjent hvor mange offermiljøer som faktisk ble kompromittert, eller om en annen fase av skadevaren ble levert via GitHub dead drop-kanalen. Ingen har tilskrevet angrepet en aktør, og Socket har ifølge The Hacker News ikke funnet bevis som kobler angrepet til LiteLLMs kompromittering i mars – om en slik kobling finnes, er dermed et åpent spørsmål (The Hacker News).