Er is opnieuw alarm geslagen rond de LiteLLM supply chain: de populaire LiteLLM Python-bibliotheek is gecompromitteerd binnen een software supply chain-aanval. Volgens meerdere melders gaat het om een schadelijke release die niet alleen data probeert te stelen, maar ook een vorm van heimelijke functionaliteit kan activeren.
De impact is direct relevant voor teams die LiteLLM gebruiken in ontwikkeling en integraties met cloud- en AI-tools. Inmiddels zijn de getroffen artefacten op PyPI in quarantaine gezet en zijn de kwaadaardige Docker-images verwijderd, maar wie de besmette versies heeft binnengehaald, moet nu actie ondernemen.
Wat is er gebeurd met de LiteLLM supply chain?
De aanval draait om LiteLLM versie 1.107.0. Die versie is verspreid via PyPI wheels en Docker images. Meerdere partijen die de zaak onderzochten rapporteren dat de gepubliceerde componenten werden ingezet om credentials te verzamelen en daarnaast een achterdeurachtige activiteit mogelijk te maken.
De onderzoekende partijen melden dat LiteLLM de getroffen package heeft laten quaranten op Python Package Index (PyPI). Ook zijn de kwaadaardige Docker images inmiddels verwijderd. Tegelijk loopt het onderzoek naar de oorspronkelijke aanvalsroutes nog.
Hoe werd de kwaadaardige release mogelijk?
LiteLLM stelt dat de kwaadwillende handelingen zijn uitgevoerd via drie GitHub-account van ingenieurs. De aanvaller zou daarbij gebruik hebben gemaakt van gestolen GitHub CLI OAuth-tokens.
In de reconstructie wordt beschreven dat de aanvaller één account inzette om een release-proces te starten, en een ander account om die release goed te keuren. Alle betrokken tokens zijn inmiddels ingetrokken.
Omdat nog niet duidelijk is hoe de tokens zijn verkregen, kan LiteLLM niet op voorhand garanderen dat er geen extra toegang tot de betreffende GitHub-accounts is geweest. Als tijdelijke maatregel is daarom de GitHub-organisatie beperkt tot één gebruiker, nadat alle andere accounts waren verwijderd.
Welke onderdelen zijn getroffen?
De analyse wijst naar een reeks bestanden die allemaal behoren bij LiteLLM 1.107.0. Concreet gaat het om verschillende wheel-varianten voor macOS, Linux en Windows, plus een tar.gz-pakket:
- litellm-1.107.0-cp310-abi3-macosx_10_12_x86_64.whl
- litellm-1.107.0-cp310-abi3-macosx_11_0_arm64.whl
- litellm-1.107.0-cp310-abi3-manylinux_2_28_aarch64.whl
- litellm-1.107.0-cp310-abi3-manylinux_2_28_x86_64.whl
- litellm-1.107.0-cp310-abi3-musllinux_1_2_aarch64.whl
- litellm-1.107.0-cp310-abi3-musllinux_1_2_x86_64.whl
- litellm-1.107.0-cp310-abi3-win_amd64.whl
- litellm-1.107.0.tar.gz (bevat geen payload-bestanden, maar wel een aangepast pyproject.toml)
Wat deed de malware precies?
Volgens de technische analyse bevat de kwaadaardige versie een credential stealer en een tweede component die op de achtergrond kan functioneren. De eerste payload wordt door onderzoekers aangeduid als een verzamelmodule met de naam privcollect.
Stealing vóórdat LiteLLM zelfs geïmporteerd wordt
Een opvallend detail: de schadelijke code kan al gestart worden voordat LiteLLM daadwerkelijk wordt geïmporteerd. Dat gebeurt via een path file met de naam cook.pth. Dit type bestand is ontworpen om code automatisch uit te voeren bij het opstarten van de Python-interpreter.
De cook.pth-bestandsregel laadt vervolgens een module die de credential collector start. Daardoor kunnen systemen al bij omgeving-opstart, of bij vroeg Python-gebruik, getroffen worden zonder dat developers het doorhebben.
Welke gegevens worden verzameld?
De verzamelde informatie omvat onder andere:
- cloud-credentials (tokens) en toegangssleutels
- private keys
- authenticatiebestanden voor AI-development tools
- browserdata gekoppeld aan Chromium en Firefox
- omgevingvariabelen (environment variables)
Daarnaast kan de malware gericht LiteLLM deployments beïnvloeden om proxy-opgeslagen credentials en modelconfiguratie te proberen te extraheren. De data wordt vervolgens gebundeld in een GZIP-gecomprimeerd TAR-archief en verstuurd via een HTTP POST naar een gezondheidseindpunt op litellm[.]dev/healthcheck.
Backdoor-achtig gedrag en externe “dead drop”
De tweede payload maakt een achtergrondproces aan dat elk uur een GitHub “dead drop” controleert. Vervolgens draait het de Python-code die de aanvaller aanbiedt. In de waarnemingen is ook een controlemechanisme beschreven waarbij een tekstbestand met een domein wordt gelezen; als dat domein bestaat, worden daar opdrachten opgehaald en uitgevoerd.
In het specifieke geval dat is geanalyseerd geeft de betreffende GitHub-repository op dit moment een 404-melding terug, maar dat sluit niet uit dat er varianten of eerdere routes zijn gebruikt.
Wat moet je nu doen als je LiteLLM 1.107.0 gebruikte?
Gebruikers krijgen geadviseerd om de stappen te volgen die bedoeld zijn om herinfectie en verdere datadiefstal te beperken. Omdat het om credentialdiefstal gaat, ligt de nadruk op het beperken van gevolgen.
- Revoke en vervang alle blootgestelde credentials vanuit een schone omgeving.
- Pin LiteLLM terug naar 1.106.2 en pin bij voorkeur op basis van digest, zoals aanbevolen.
- Controleer of je eerder de getroffen versie hebt geïnstalleerd via PyPI of Docker.
- Vervang Docker-omgevingen waar mogelijk met de geverifieerde/veilige varianten.
Heb je LiteLLM geïntegreerd in CI/CD of werkplekken van developers? Dan is extra aandacht nodig voor tokens die door pipelines, lokale scripts of build-omgevingen zijn gebruikt.
Waarom dit ook raakt aan bredere supply chain-risico’s
Deze casus past in een terugkerend patroon: aanvallers mikken niet op een bug in je toepassing, maar op de softwareketen die je vertrouwt. Wanneer een pakket wordt gemanipuleerd, kan dat leiden tot datadiefstal nog vóórdat de code in jouw project “zichtbaar” wordt.
Wil je je aanpak verdiepen, dan is het nuttig om vergelijkbare incidenten te bekijken. Bijvoorbeeld: PHP2Shell: aanpak bij gelekte PHP-lekken laat zien hoe aanvallers via supply-achtige paden en misbruik van componenten snel impact kunnen krijgen.
Snelle checklist voor teams met AI- en developmentomgevingen
Om de gevolgen te beperken, kun je de volgende praktische vragen meenemen in je incidentrespons:
- Welk hosts/containers hebben LiteLLM 1.107.0 gedraaid (of kunnen dat hebben gedaan)?
- Welke credentials werden recent gebruikt op die omgeving (cloud tokens, API keys, browserprofielen, IDE-auths)?
- Is je dependency management ingericht om direct te pinnen op digests en snelle rollback mogelijk te maken?
- Kunnen medewerkers verdachte installaties makkelijk detecteren en vervangen via clean images?
Door de focus op credentials is het daarbij verstandig om niet alleen de bibliotheek te vervangen, maar ook de identiteitssporen eromheen (tokens, secrets, sessies) systematisch te herzien.
Conclusie
De LiteLLM supply chain-incidenten laten opnieuw zien hoe kwetsbaar moderne development- en AI-omgevingen kunnen zijn wanneer een populaire dependency gecompromitteerd raakt. Hoewel PyPI de getroffen package inmiddels heeft gequarantineerd en Docker-images zijn verwijderd, blijft het risico bestaan voor iedereen die 1.107.0 al heeft geïnstalleerd.
Door snel credentials in te trekken en te vervangen, en door terug te schakelen naar een veilig geverifieerde versie (met digest pinning), verklein je de kans dat gestolen toegang nog te gebruiken valt.
Bron: https://thehackernews.com/2026/10/litellm-compromised-in-supply-chain.html
