Supply chain-aanval op LiteLLM: wat te doen als u 1.107.0 installeerde

LiteLLM is een veelgebruikte gateway tussen applicaties en modelaanbieders zoals OpenAI, Anthropic en Google. Op 21 oktober 2026 zetten aanvallers een besmette versie van LiteLLM op PyPI en Docker Hub: versie 1.107.0. Deze supply chain-aanval op LiteLLM stal cloudgegevens en API-sleutels voor AI van elke machine die de versie installeerde. Gebruikt uw team LiteLLM? Controleer uw systemen dan vandaag nog.

Welke versies en images zijn besmet

Het incidentrapport van LiteLLM noemt deze besmette onderdelen:

Kanaal	Besmet	Periode op 21 oktober (UTC)
PyPI	`litellm==1.107.0`, alle zeven wheels	11:39 tot 13:23
Docker Hub	tags `v1.107.0`, `latest`, `main-latest`, `main-stable`	11:46 tot 14:20
GHCR	dezelfde vier tags	11:46 tot 13:51

Volgens LiteLLM zijn alle eerdere versies veilig. De officiële broncode van v1.107.0 op GitHub bevat de schadelijke bestanden niet. Enterprise-klanten met de private registry zijn niet geraakt.

U loopt risico als een installatie of container in die periode een niet-vastgezette versie of een van deze tags gebruikte. CI-pipelines en containers die latest ophalen, lopen het grootste risico.

Wat de malware doet

Datadog Security Labs heeft de release onderzocht. De release zet drie bestanden in site-packages: cook.pth, cook.py en sitecustomize.py. Python voert .pth-bestanden en sitecustomize.py bij elke start uit. Elk Python-proces in de omgeving start dus de malware, ook als het LiteLLM nooit importeert.

De malware verzamelt onder meer:

inloggegevens voor AWS, GCP en Azure, ook uit de metadata van de server;
geheimen van Kubernetes, Docker, Vault en Terraform;
SSH-sleutels, tokens voor Git, npm en PyPI, .env-bestanden en de shellgeschiedenis;
API-sleutels van LLM-aanbieders en sessies van AI-tools voor ontwikkelaars, zoals Claude, Codex en Cursor;
de sleutels van modelaanbieders in de database van de LiteLLM-proxy, als die database bestaat.

Een tweede bestand is een achterdeur. Elk uur vraagt het een extern adres om nieuwe code en voert die uit. Datadog zag op het moment van de analyse nog geen tweede aanvalsfase. Verwijdert u alleen de map van het litellm-pakket? Dan blijven de drie bestanden staan.

De aanvaller gebruikte de buit snel. Help Net Security beschrijft onderzoek van Wiz. Ongeveer vierenhalf uur na de diefstal testte de aanvaller AWS-gegevens van besmette CI-runners en Kubernetes-nodes. De aanvaller controleerde ook de toegang tot Amazon Bedrock.

Hoe de aanvallers binnenkwamen

Het rapport over de aanvalsketen begint bij één sleutel. Op 27 mei 2026 kwam een beheerderssleutel van een intern LiteLLM-platform in een openbare repository terecht. Niemand trok de sleutel in. Vier maanden later werkte hij nog. Daarmee kreeg de aanvaller een GitHub-token van een eigenaar van de organisatie. Met meer gestolen tokens liet de aanvaller de release-pipeline daarna bouwen vanuit een nagemaakte repository.

Het is al de tweede supply chain-aanval op LiteLLM in 2026. Datadog koppelt een eerder incident in maart, met de versies 1.82.7 en 1.82.8, aan de TeamPCP-campagne. Een verband tussen de twee aanvallen had Datadog bij publicatie niet gevonden.

Wat u nu moet doen

LiteLLM geeft deze stappen. Volg ze in deze volgorde.

Begin niet met pip install. Elke start van Python in een besmette omgeving voert de malware opnieuw uit, ook pip.
Zoek naar sporen. Zoek naar litellm-1.107.0.dist-info, cook.pth en sitecustomize.py. Zoek ook naar containers die de image met digest sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e draaiden. Vindt u niets? Dan is de server nog niet bewezen schoon.
Verwijder de bestanden vanuit de shell. Verwijder cook.pth, cook.py, sitecustomize.py en hun .pyc-bestanden uit elke besmette site-packages. Stop het Python-proces dat /tmp/remote_code_loader.lock vasthoudt.
Bouw opnieuw. Bouw images en virtuele omgevingen vanaf nul. Zet litellm==1.106.2 of een andere expliciete, eerdere versie vast.
Ga ervan uit dat de diefstal gelukt is. Doe dit voor elke server met uitgaande internettoegang.
Vervang sleutels vanaf een schone machine. Vervang de IAM-rol van de server, elke aanbiederssleutel in de database van de LiteLLM-proxy, de master- en virtuele sleutels, het databasewachtwoord en alle geheimen in de omgeving van de server.
Controleer uw cloudlogs. Zoek in AWS CloudTrail naar GetCallerIdentity-aanroepen rond het moment van installatie. Zoek daarna naar gebruik van die gegevens van buiten uw infrastructuur.

Doe daarnaast drie dingen voor de lange termijn:

Zet in productie en CI exacte versies en image-digests vast. Zet geen latest in productie.
Geef de gateway eigen sleutels met lage bestedingslimieten. Dan kost een gestolen sleutel minder.
Scan uw openbare repositories op geheimen en trek elke uitgelekte sleutel direct in. De aanval op LiteLLM begon met een sleutel die niemand had ingetrokken.

Hoe wij dit aanpakken

Een LLM-gateway bewaart de sleutels van alle modelaanbieders die u gebruikt. Daarom is het een waardevol doelwit. Voor een financiële dienstverlener bouwden we een eigen AI-werkomgeving met meerdere agents. Een API-laag tussen de agents en de modelaanbieders registreert het gebruik en cachet de antwoorden. Zo’n laag behandelen we als kritieke infrastructuur, en we passen de checklist hierboven erop toe.