LiteLLM 1.107.0 verspreidt infostealer en RAT

LiteLLM 1.107.0 verspreidde op 21 oktober malware via alle zeven PyPI-wheels en officiële Docker-images, melden Aikido en StepSecurity; het project haalde de besmette artefacten die dag weg.

Voor Nederlandse organisaties die LiteLLM als AI-gateway inzetten, kon een Python-start op een getroffen machine bedrijfsgegevens blootleggen: model-API-sleutels, de LiteLLM-proxydatabase, cloudtoegang, browsergegevens, SSH-sleutels en CI-tokens. Eén besmette bouwrunner kan zo tegelijk de modeltoegang, cloudinfrastructuur en softwarebouw raken.

De payload startte zonder LiteLLM-import

De besmette bestanden zaten in de gecompileerde wheels en containerimages. De officiële brontag van versie 1.107.0 bevatte de malware niet, terwijl de release uit een door aanvallers beheerde gelijkende repository werd gebouwd. Volgens LiteLLM zijn drie ontwikkelaarsaccounts misbruikt, vermoedelijk via gestolen OAuth-tokens voor GitHub CLI. Eén account wijzigde het releaseproces en startte de bouw, een tweede keurde de productiepublicatie goed en een derde verwijderde de workflowlogs. Hoe de aanvallers de tokens verkregen, was in het incidentbericht nog niet vastgesteld.

De zeven wheels stonden van 11:39:51 tot 13:23 UTC op PyPI; GHCR haalde de besmette tags uiterlijk om 13:51 weg en Docker Hub om 14:20, blijkt uit de tijdlijn van LiteLLM. De kwaadaardige bestanden waren cook.pth, cook.py en sitecustomize.py, geplaatst in Python’s site-packages. De .pth-instructie start cook.py bij iedere Python-start. Een aparte import van LiteLLM was dus niet nodig: ook een test, een pip-commando of de gateway zelf kon de code activeren.

Aikido beschrijft dat de infostealer browserwachtwoorden, cloudtoegang en API-sleutels voor modelleveranciers probeerde te verzamelen. De payload keek ook naar SSH- en GPG-sleutels, Kubernetes-tokens, CI-geheimen, omgevingsvariabelen en API-sleutels van modelproviders in de LiteLLM-database. Eén besmette bouwrunner kon daardoor meer prijsgeven dan de sleutels waarmee LiteLLM modellen aanroept.

Een tweede component was malware voor bediening op afstand (RAT). Die controleerde op Linux en macOS elk uur een GitHub-repository op opdrachten en kon externe Python-code ophalen. Wiz had geen bewijs dat deze tweede codefase actief was, maar zag die dag wel inloggegevens van AWS-rollen uit besmette CI- en Kubernetes-omgevingen door de aanvallers testen, met aanvragen om AWS-identiteiten en beschikbare modellen op te vragen.

Herstel begint bij de hele omgeving

LiteLLM adviseert gebruikers die versie 1.107.0 installeerden of een getroffen image startten de host als gecompromitteerd te behandelen. Dat geldt voor de publieke PyPI-release en de tags v1.107.0, latest, main-latest en main-stable op Docker Hub en GHCR. LiteLLM meldt dat de private enterprise-uitgave niet geraakt was. PyPI heeft versie 1.107.0 in quarantaine geplaatst en verwijst naar 1.106.2 als alternatief.

Herstel vraagt om een schone herbouw en vervanging van alle sleutels en tokens die de host kon lezen. Start geen pip in de getroffen omgeving: dat commando kan Python openen en de payload opnieuw activeren. LiteLLM adviseert versie 1.106.2. Tot de te vervangen waarden behoren API-sleutels van modelproviders uit de proxydatabase, de master- en virtuele sleutels, het databasewachtwoord, cloudrollen, omgevingsvariabelen en tokens voor CI, containers en codeopslag. Controleer daarna auditlogs op gebruik vanaf een onbekende omgeving. Ontbreekt het tijdelijke markerbestand van de malware, dan bewijst dat niet dat er geen gegevens zijn verstuurd.

Dezelfde AI-gateway raakte in maart al besmet

Dit is de tweede besmetting van LiteLLM via PyPI in 2026, maar de aanvalsketen verschilde. In maart verschenen de met malware besmette versies 1.82.7 en 1.82.8 nadat een gekaapte Trivy-build toegang tot de publicatieketen gaf. Onderzoek naar die eerdere aanval koppelde 118.829 gedumpte runners aan 2.488 bedrijfsdomeinen. Dat cijfer telde domeinen in buitgemaakte data, niet een bewezen inbraak bij elk bedrijf.

In een afzonderlijk dossier waarschuwde de FBI voor TeamPCP, dat LiteLLM en Trivy als doelwitten had. Het bureau adviseerde ook een minimale pakketleeftijd van zeven dagen, zodat een verdachte release eerst kan worden ontdekt. Bij een gateway die software zonder vastgepinde versies bijwerkt, verkleint zo’n wachttijd de kans dat een nieuwe release meteen in productie draait.

Voor bredere preventie beschrijft de gids over pakketten vastpinnen, herkomst controleren en een softwarelijst (SBOM) bijhouden hoe teams afhankelijkheden in kaart kunnen brengen.

De omvang van de besmetting blijft onbekend

LiteLLM’s incidentbericht was om 16:00 UTC voor het laatst bijgewerkt. Daarin stond nog niet hoe de OAuth-tokens waren verkregen. Ook noemde geen van de geraadpleegde bronnen een geverifieerd aantal besmette omgevingen of een totaal van buitgemaakte sleutels en tokens. Wiz zag wel inloggegevens van AWS-rollen getest worden, maar dat bewijst niet dat alle aangetroffen wachtwoorden en sleutels zijn gebruikt.

Voor getroffen teams bepaalt wat de host kon lezen welke sleutels moeten worden vervangen en welke logs moeten worden doorgelicht. Aantoonbare exfiltratie is daarvoor geen voorwaarde.