Op 21 oktober werd de open source proxy LiteLLM getroffen door een LiteLLM supply chain aanval. Daarbij werden kwaadaardige varianten van een specifieke versie via zowel PyPI als Docker aan gebruikers aangeboden. De pakketten waren slechts enkele uren beschikbaar, maar zijn naar schatting meer dan 49.000 keer gedownload.
De impact is niet voor iedereen gelijk: LiteLLM stelt dat klanten die uitsluitend via de private repository haalden, niet zijn geraakt. Maar als jij versie 1.107.0 hebt geïnstalleerd binnen de periode dat de boze pakketten actief waren, dan is actie echt noodzakelijk.
Wat er precies is gebeurd bij de LiteLLM supply chain aanval
Het incident draait om LiteLLM versie 1.107.0, een populaire open source proxy voor het routeren van requests over verschillende LLM-providers. In de aanval werden gemanipuleerde packages online gezet, zodat ze door gebruikers als normale installatiepakketten konden worden gedownload.
Volgens de beschikbare informatie waren de schadelijke pakketten ongeveer drie uur beschikbaar. Tijdens die korte window zijn ze naar schatting 49.000+ keer gedownload. LiteLLM verwijderde de besmette packages weer van PyPI.
Daarnaast werd ook gekeken naar de container-kant: Docker Hub tags en image-varianten werden verwijderd of omgezet naar schone artifacts.
Hoe konden aanvallers in de build en publicatie komen?
LiteLLM meldt dat aanvallers GitHub CLI OAuth-tokens buitmaakten. Die tokens zouden gekoppeld zijn aan een “unexpected, innocuously named” gebruikersaccount binnen de interne LiteLLM-omgeving, een account dat blootstond aan het publieke internet.
De tokens zijn waarschijnlijk gelekt via Claude Code. In bepaalde situaties zou Claude Code OAuth-tokens kunnen teruggeven in de response-body, waarna die in logbestanden van LiteLLM terechtkwamen. De aanvallers zouden die logbestanden vervolgens hebben gebruikt om de tokens terug te vinden.
Er blijft wel onduidelijkheid bestaan over de exacte route: hoe de aanvallers precies toegang kregen tot de interne deployment en hoe ze lateraal konden bewegen. Wel is zeker dat ze over drie sets developer GitHub CLI-credentials beschikten.
Van gestolen credentials naar “gepoisoned” publicatie
Met de gecompromitteerde credentials konden aanvallers de workflow rond releases beïnvloeden. In hoofdlijnen beschrijft LiteLLM het volgende aanvalspad:
- Ze schakelden branch protections uit.
- Ze voegden een wijziging samen die de releaser naar een ander bronrepository wees.
- Ze draaiden een gecompromitteerde GitHub workflow die naar een “lookalike” repository wees.
- Daarna ondertekenden en publiceerden ze de vergiftigde (poisoned) artifacts.
Wie liep risico en wat maakte de malware gevaarlijk?
Gebruikers die de besmette LiteLLM-versie 1.107.0 binnen de compromisperiode installeerden, kregen een payload met twee kerncomponenten: een information stealer (info-stealer) en een RAT (remote access trojan).
LiteLLM geeft aan dat enterprise customers die via een private repository trokken, niet zouden zijn beïnvloed. Desondanks blijft het voor individuele omgevingen die publieke packages hebben gebruikt essentieel om te controleren.
Welke gegevens probeerde de payload te stelen?
De informatie-stealer richtte zich op een brede set aan data. De payload werd bij uitvoering zo gebouwd dat hij drie bestanden uitpakt naar de site-packages root, zodat Python-interpreterruns direct effect konden hebben.
Bij het opstarten:
- laden ze de stealer die systeeminformatie verzamelt;
- ze richten zich op browser credentials en cookies;
- ze verzamelen developer credentials, omgevingvariabelen en cloud secrets (AWS, GCP en Azure);
- ze zoeken naar API-sleutels voor AI-tools, waaronder Anthropic, GitHub Copilot en OpenAI;
- ze proberen SSH private keys, shell history en GPG keys te bemachtigen.
Vervolgens wordt de gestolen informatie versleuteld en doorgestuurd naar litellm[.]dev.
LLMjacking en command-and-control signalen
Wiz stelt dat aanvallers rond 4,5 uur na exfiltratie begonnen met misbruik van de gestolen credentials. Wiz zag aanvallers Amazon Bedrock-modellen aanroepen met de gestolen AWS-gegevens, wat past bij LLMjacking (misbruik van AI-accounts of compute via gestolen tokens/keys).
Daarnaast werd de RAT-component waargenomen die regelmatig contact maakt met een command-and-control (C&C)-server. Volgens StepSecurity checkt de RAT ook elk uur een “GitHub dead drop” en voert vervolgens de Python-code uit die de aanvaller aanbiedt.
Welke acties moet je nu nemen?
Als je LiteLLM gebruikt, behandel dit als een direct incident. De aanbevelingen die uit de beschikbare informatie volgen:
- Verwijder LiteLLM versie 1.107.0 onmiddellijk.
- Roteer je credentials (API keys, tokens en wachtwoorden) die beschikbaar waren in de omgeving waar LiteLLM draaide.
- Voer een malware-scan uit en controleer systemen op verdachte persistence en netwerkverkeer.
- Gebruik de meest recente schone versie: LiteLLM noemt 1.106.2 als laatst bekende clean release.
Omdat de payload gegevens uit meerdere bronnen probeert te verzamelen (van cloud secrets tot browserdata), is het belangrijk om niet alleen het pakket te verwijderen, maar ook de vertrouwensketen eromheen te herstellen.
Waarom dit incident extra relevant is voor AI-agenten
Dit soort aanvallen laat zien hoe kwetsbaar de hele toolchain kan zijn: een supply chain compromise verandert van “slechts een package” naar directe toegang tot accounts, API’s en data. Zeker bij AI-agenten draait veel werk om authenticatie en externe integraties—precies de dingen waar de stealer op mikt.
Wil je breder inzicht in hoe AI-agenten misbruikt kunnen worden of welke risico’s bij runtime spelen? Lees dan ook AI-agenten als insider threat: wat je nu ziet en AI-agent runtime security: Beacon en beleid.
Praktische checklijst voor teams
Om te voorkomen dat dit soort incidenten bij een volgende release opnieuw doorwerken, kun je intern gericht controleren:
- Welke omgevingen draaiden met LiteLLM 1.107.0?
- Waar komen packages binnen (CI/CD, requirements files, Docker build pipelines)?
- Zijn er logs die mogelijke token-lekken of ongebruikelijke workflow-acties kunnen aantonen?
- Welke cloud keys en API-tokens stonden beschikbaar voor de runtime van Python en containers?
Door deze vragen snel te beantwoorden, beperk je de kans op vervolgschade en maak je gerichte remediatie mogelijk.
Conclusie
De LiteLLM supply chain aanval toont hoe snel een supply chain incident kan escaleren: gestolen GitHub CLI-tokens leidden tot gemanipuleerde artifacts die via PyPI en Docker werden verspreid. Hoewel de kwaadaardige packages slechts kort online stonden, zijn er naar schatting tienduizenden downloads geweest.
Als je de getroffen versie gebruikte, moet je nu handelen: verwijder, roteer, scan en monitor. Daarmee doorbreek je de kans op misbruik van gestolen credentials en verminder je het risico op verdere compromittering.
Bron: https://www.securityweek.com/litellm-compromised-in-fresh-supply-chain-attack/
