Er is een nieuw supply-chain incident in omloop waarbij Malicious LiteLLM kort op PyPI terechtkwam. In de bronrapportage wordt beschreven dat de besmette releases zijn ontworpen om gevoelige gegevens te verzamelen uit omgevingen waar ze werden geïnstalleerd, en die vervolgens naar een aanvallersdomein te sturen.
Het gaat niet alleen om “een pakket dat niet klopt”. De kern van het risico zit in de waarde van de secrets die automatisch aanwezig zijn op build- en run-systemen. Denk aan cloud-sleutels, SSH-keys en tokens voor Kubernetes en databanken. In dit artikel lees je wat er bekend is, waarom de impact lastig te schatten is, en vooral: welke acties je vandaag al kunt uitvoeren.
Wat er precies speelde met Malicious LiteLLM
Volgens de beschrijving zaten twee kwaadaardige LiteLLM-releases rond 24 maart gedurende ongeveer 40 minuten op PyPI. Ze waren bedoeld als onderdeel van een open-source AI-gateway waarmee applicaties verbinding maken met verschillende modelproviders.
De incidentdocumentatie noemt specifiek de versies 1.82.7 en 1.82.8 als gecompromitteerd. LiteLLM stelt dat deze versies live waren tussen 10:39 UTC en tot ongeveer 16:00 UTC, waarna PyPI ze in quarantaine plaatste. Voor de gebruiker betekent dit: een installatie in dat tijdvak moet je beschouwen als verdacht.
In de bron wordt ook genoemd dat versie 1.82.8 een bestand bevatte met de naam litellm_init.pth. Zulke bestanden worden geladen bij het opstarten van Python-processen, waardoor de code kon draaien zodra er Python in de betreffende omgeving startte—ook als LiteLLM zelf niet expliciet werd geïmporteerd.
Welke data een installatie kon stelen
De besmette packages zouden meerdere soorten secrets uit de omgeving ophalen. De bron noemt onder meer: environment variables, SSH-keys, cloud credentials, Kubernetes-tokens en database passwords.
Daarna werden de gestolen gegevens gecodeerd en verstuurd richting een domein dat door de aanvallers werd beheerd. Het domein zou losstaan van het LiteLLM-project.
Een belangrijk detail uit de bron: de vraag is niet primair of een team bewust LiteLLM gebruikte, maar of iets op een systeem LiteLLM (of een transitive dependency) heeft geïnstalleerd. Het project en de analyses wijzen erop dat een niet-vastgepinde dependency via een agent framework of orchestratie-tool alsnog tot het installeren van het besmette pakket kon leiden.
Waarom aantallen en “slachtoffers” lastig te duiden zijn
In de bron geeft CloudSEK aan datasetmateriaal te hebben dat is samengesteld uit grofweg 434.000 bestanden die aanvallers zouden hebben buitgemaakt, met mapping naar meer dan 2.100 organisaties. In de vervolgartikeling staat echter dat dit geen harde telling is van getroffen eindgebruikers; het zou gaan om loot- en logbestanden die werden gelinkt aan een campagne, niet om bewijs dat credentials daadwerkelijk bij alle genoemde organisaties zijn gebruikt.
De bron legt uit hoe “match”-scores tot stand komen. Er worden identiteitssignalen gebruikt uit de CI-runner-omgeving, zoals hostidentiteit en committerdomeinen, en daarbij moet het eigen domein van de organisatie passen om een hoge score te krijgen. Namespace-gegevens zouden minder zekerheid geven (medium confidence).
Omdat die nuance ontbreekt in de meeste headlines, luidt het advies in de bron pragmatisch: rotate in plaats van wachten op bewijs. Anders gezegd: als je in het tijdvak zat, is het verstandiger je secrets direct te vervangen dan te speculeren over de daadwerkelijke misbruikstappen.
Koppel met de Trivy hack en CVE-registratie
Het LiteLLM-incident staat niet op zichzelf. De bron beschrijft een bredere campagne: TeamPCP, die wordt gelinkt aan de Trivy-scanner van Aqua Security. Google trackt TeamPCP als UNC6780.
In de beschrijving staat dat aanvallers toegang konden behouden na een niet-volledige credential rotation. Op 19 maart zouden ze bovendien kwaadaardige commits hebben force-pusht naar tags van 76 van de 77 trivy-action versies en naar alle zeven setup-trivy tags, terwijl tegelijk een kwaadaardige Trivy release (genaamd 0.69.4) werd gepubliceerd.
De impact is later ook publiek gecatalogiseerd: het ecosysteem-compromis is geregistreerd als CVE-2026-33634 en toegevoegd aan de CISA Known Exploited Vulnerabilities lijst op 26 maart. Later is in de bron bevestigd dat het CVE-record ook LiteLLM 1.82.7 tot en met 1.82.8 als getroffen componenten noemt naast de Trivy-onderdelen.
3 stappen om je risico te beperken
De bron geeft een concreet driesporenplan voor organisaties die willen inschatten of ze geraakt zijn. Je kunt dit zien als een checklist voor CI/CD-hygiëne rondom de blootstellingsperiode.
1) Controleer installaties in het auditvenster
Ga na of LiteLLM 1.82.7 of 1.82.8 is geïnstalleerd op systemen gedurende het auditvenster dat in de bron wordt genoemd: 10:39 tot 16:00 UTC op 24 maart. Let daarbij niet alleen op directe installaties, maar ook op het bredere mechanisme van transitive dependencies.
2) Rotate alle secrets die tijdens die periode konden werken
Als je systemen mogelijk blootgesteld zijn geweest, is het kernadvies om credentials te roteren. De bron benadrukt dat langdurig gekopieerde geheimen bruikbaar kunnen blijven, zelfs als het pakket later is verwijderd of in quarantaine is geplaatst.
De richtlijn is daarom gericht op wat je geheimen konden lezen of gebruiken, niet op de exacte vraag of de malware daadwerkelijk is uitgevoerd op jouw organisatie. Dat sluit ook aan bij adviezen van overheidsinstanties die in de bron worden genoemd: rotate CI/CD-secrets en publicatietokens, en vervang langdurige tokens waar mogelijk door tijdelijke varianten.
3) Zoek in GitHub op campagnedetectie-strings
Tot slot raadt de bron aan om in GitHub-organisaties te zoeken naar repository-naamindicatoren die aan de campagne worden gekoppeld: tpcp-docs of docs-tpcp. De beschrijving waarschuwt dat een exacte naammatch kan missen, omdat er in de campagne ook asset-namen worden gebruikt die met een prefix beginnen en een timestamp bevatten.
Praktisch betekent dit: kijk niet alleen naar “verdachte” repos, maar ook naar anomalieën in releases en artifacts die in korte tijd zijn aangemaakt.
Wat je kunt leren voor je supply-chain aanpak
Deze casus onderstreept een trend die je in securitynieuws vaker ziet: aanvallen verschuiven van uitsluitend “exploiteer een app” naar “manipuleer het pad waarlangs software wordt gepubliceerd of geïnstalleerd”. De bron plaatst het incident expliciet binnen een supply-chain campagne rond CI/CD en scanners.
Daarmee wordt het ook duidelijk waarom korte blootstellingsvensters toch grote impact kunnen hebben. In een CI-omgeving staan vaak precies de secrets die een aanvaller wil: tokens voor publiceren, sleutels voor cloud-accounts en toegang tot omgevingen. Als een kwaadaardig pakket die context aantreft, kan het direct misbruik maken.
Wil je breder kijken naar hoe vergelijkbare patch- en supply-chain risico’s zich voordoen bij bekende leveranciers, dan kun je ook deze artikelen lezen: Bron: https://thehackernews.com/2026/08/malicious-litellm-releases-tied-to.html
