LiteLLM waarschuwt voor een LiteLLM token-lek dat in verband wordt gebracht met een gecompromitteerde release-pipeline. Het gevolg: een schadelijke versie van het Python-pakket en bijbehorende Docker-images die een credential stealer én een backdoor/RAT-functie bevatten. Wie destijds een niet-gepinde versie installeerde, of een getroffen container gebruikte, loopt risico.
De feiten in het kort: rond 4:00 a.m. PST op 21 oktober 2026 verschenen er nieuwe releases op PyPI en registries voor Docker. De gepoisoned release was bedoeld om gegevens te verzamelen, door te sturen en op een later moment remote code te kunnen uitvoeren.
Wat er is misgegaan bij de LiteLLM token-lek
De aanvallers zouden meerdere onafhankelijke beveiligingsmaatregelen hebben omzeild om een kwaadaardige package release te pushen. De betrokken versies waren onder andere:
- LiteLLM v1.107.0 (PyPI)
- v1.107.0 en tags als latest, main-latest en main-stable voor Docker Hub
- dezelfde set tags voor GHCR
Gebruikers werden impacted wanneer ze in een specifiek tijdvak een unpinned install deden via pip, of wanneer ze de container image met die tags gebruikten. Dat maakt het voor organisaties lastig: als je geen exacte versielogboeken hebt, weet je mogelijk niet welke hosts daadwerkelijk de geïnfecteerde artifacts binnenkregen.
Waarom de payload zo “breed” inzetbaar was
De schadelijke versie bevatte code om onder meer credentials en sleutels te oogsten en tegelijkertijd willekeurige code uit te voeren vanuit een externe server, met een terugkerend interval van ongeveer elk uur. Daarmee veranderde de component feitelijk in een remote access trojan (RAT).
Technisch gezien startte de aanval via een methode die door de Python interpreter wordt opgepakt: een padbestand (cook.pth). Daarin stond een commando om een Python module (cook.py) te importeren. Die code ontfutselde zichzelf via obfuscation en startte vervolgens een stealer-routine met de naam privcollect.
Daarna volgden drie belangrijke stappen:
- Gegevens verzamelen: systeeminformatie en secrets uit browser-, development-, cloud- en AI-toolcontexten.
- Exfiltratie: verzending via een HTTP POST naar een LiteLLM-domein voor healthcheck.
- Stage load/remote uitvoering: op Linux en macOS probeerde de malware een sitecustomize.py script uit te voeren dat extra second-stage code kan ophalen.
De tweede fase downloadde een script (aangeduid als /codepy) van een aanvallersdomein. Opvallend detail is dat de geleverde achtergrondtaak een lockbestand gebruikt om meerdere instantiaties te voorkomen en vervolgens in een oneindige lus de huidige “command & control” informatie ophaalt.
Van data stelen naar misbruik in de cloud
Volgens rapportage zag Wiz (Google’s cloud security dochter) misbruik van gestolen credentials starten ongeveer 4,5 uur na de exfiltratie. Daarbij werd gekeken naar AWS-instance role credentials die waren vastgelegd via CI runners en Kubernetes nodes.
De aanvallers valideerden de verkregen rollen met een call als sts:GetCallerIdentity en voerden vervolgens acties uit die passen bij LLMjacking. In sommige omgevingen breidden ze dit uit met IAM-enumeratie (zoals het ophalen van rollen en gebruikers) en algemene discovery van accounts en trails.
Concreet werden er calls waargenomen rond het ophalen van foundation model lijsten en het opsommen van modellen. Daardoor is het risico niet alleen “datakopie”, maar ook “actief gebruik” van je cloudrechten tegen jouw omgeving.
Hoe konden aanvallers releases pushen ondanks eerdere harde maatregelen?
LiteLLM had al beveiligingen ingevoerd na een vergelijkbaar incident eerder dat jaar. De maatregelen waarover LiteLLM zegt te beschikken omvatten onder meer:
- releases verplaatsen naar een private repository
- Docker release tags immutable maken
- Docker images signen
Toch ging het mis nadat de maintainer-community tijdelijk de release-permissies vergrootte. Twee interne engineers kregen ruimte om dagelijks bugfix backports te publiceren voor klanten. Juist in die periode zou de aanvaller gebruik hebben gemaakt van developer-toegang tot meerdere GitHub CLI credentials.
Daarbij werd ook beschreven dat een token van een GitHub organisatie owner werd benut om branch protections uit te schakelen en wijzigingen te forceren (force-push). Vervolgens werd een workflow uitgevoerd die niet naar het beoogde repository verwees, maar naar een lookalike variant. Daardoor konden de schadelijke artifacts alsnog worden gesigned en gepubliceerd.
Waar komt de LiteLLM token-lek vermoedelijk vandaan?
Een kernpunt is dat LiteLLM verwijst naar logging van GitHub CLI OAuth tokens. In specifieke scenario’s zou Claude Code een OAuth token in de response-body kunnen embedden. Als response bodies worden gelogd, kunnen tokens dus terechtkomen in LiteLLM-logs.
Daarnaast identificeerden de onderzoekers een “unexpected, innocuously named” account in een interne LiteLLM deployment dat publiek bereikbaar was. De verwachting is dat de aanvaller toegang kreeg tot die omgeving, de OAuth tokens uit de logs haalde en daarna de release workflow kon comprimeren met die verkregen credentials.
Hoe de public exposure precies ontstond en hoe de aanvaller toegang verwierf, blijft vooralsnog onzeker. LiteLLM denkt dat het mogelijk verband houdt met een kwetsbaarheid die later is gepatcht.
Actiepunten: dit moet je nu doen
LiteLLM adviseert ontwikkelaars en security teams om direct op meerdere sporen tegelijk te reageren. De belangrijkste aanbevelingen:
- Verwijder LiteLLM 1.107.0 van je machines.
- Isoleren: zet systemen waar de malware vermoedelijk actief was in quarantaine.
- Hunt op de verdachte Python artifacts.
- Block de toegang tot het exfiltratie-domein.
- Rotate alle betrokken credentials (zorg dat je “reachable” routes meeneemt).
- Onderzoek of /codepy daadwerkelijk is uitgevoerd.
JFrog-onderzoekers vatten het risico praktisch samen: een “schone” bronrepo zegt nog niet alles over wat er uiteindelijk als wheel of build artifact op je systeem belandt. Als versie 1.107.0 ergens draaide, is het verstandig om elk credential pad te herstarten en builds opnieuw op te zetten.
Vergelijkbare patronen en waarom dit supply chain breed raakt
Wat extra aandacht vraagt, is het gebruik van een .pth-bestand om de stealer aan te sturen. Dat patroon lijkt volgens onderzoekers op de modus operandi uit een eerdere aanval in maart 2026. Wel is er op dit moment geen harde aanwijzing dat het om dezelfde actor of dezelfde implementatie gaat: de exfiltratie en RSA public keys verschillen.
De bredere les blijft echter hetzelfde: supply chain aanvallen kunnen downstream effect hebben. Zelfs wanneer je broncode vertrouwt of tooling signatues hanteert, kan een compromis in permissies of CI/CD-toegang alsnog leiden tot gepubliceerde malafide artifacts.
Extra context: tokenlekken en agentische ketens
Als je in je organisatie ook werkt met agenten en AI-werkstromen die logs kunnen beïnvloeden, is het nuttig om breder te kijken dan alleen “pakketversies”. Tokenverwerking, logging en runtime-ketens kunnen dezelfde klasse risico’s introduceren. Zie bijvoorbeeld ook ons stuk over agents die veiligheidsmonitoring uitschakelden als illustratie van hoe wijzigingen in agentgedrag of instellingen impact kunnen hebben op veiligheid.
Conclusie
De melding rond de LiteLLM token-lek laat zien hoe snel een supply chain incident kan escaleren: van gecompromitteerde release permissions naar schadelijke Python/Docker artifacts, vervolgens datadiefstal en uiteindelijk misbruik van cloudrechten. Voor getroffen organisaties is tijd cruciaal: verwijder de verdachte versie, isoleer systemen, blokkeer exfiltratie en roteer credentials grondig.
Wil je dit soort aanvallen structureel voorkomen? Combineer versiebeheer met artifact-validatie, bewaak release pipeline-rollen en beperk de mogelijkheid voor ongeautoriseerde wijzigingen in workflows. Zo verklein je de kans dat een “kleine” toegangsuitbreiding leidt tot grote downstream schade.
Bron: https://thehackernews.com/2026/10/litellm-suspects-github-token-leak-in.html
