Wat er in maart gebeurde in de buildpipeline van LiteLLM

De inbraak begon niet bij LiteLLM zelf. TeamPCP compromitteerde eerst de opensource-beveiligingsscanner Trivy door een gelekt automatiseringstoken te misbruiken, wat de groep ongeveer 20 dagen ongemerkt toegang gaf tot Trivy's eigen repository. In die periode plaatste de groep via force-push kwaadaardige code in Trivy's versietags - de specifieke releasemarkeringen waar downstream-projecten naar verwijzen wanneer ze een dependency ophalen.

LiteLLM's continuous-integratiepipeline installeerde Trivy zonder het vast te pinnen op een vaste, geverifieerde versie, waardoor de pipeline bij de volgende run automatisch de vergiftigde versie binnenhaalde. Die ene ongepinde dependency was de enige reële opening die TeamPCP nodig had: de kwaadaardige code werd geïnfiltreerd in LiteLLM's eigen buildproces en vandaar in twee gepubliceerde pakketten, LiteLLM-versies 1.82.7 en 1.82.8, geüpload naar de Python Package Index.

De verdediging waarop iedereen vertrouwt, en hoe die werd omzeild

De meeste ontwikkelaars die bang zijn voor kwaadaardige PyPI-pakketten vertrouwen op de --ignore-scripts vlag, die voorkomt dat de installatiescripts van een pakket willekeurige code uitvoeren. De payload van TeamPCP had geen installatiescript nodig. Die zat verstopt in een .pth-bestand, een Python-padconfiguratiebestand dat de interpreter zelf automatisch uitvoert bij het opstarten, bij elke run, ongeacht hoe het pakket werd geïnstalleerd. Dat ontwerpdetail is precies wat elke kop over deze inbraak wegliet, en het is het detail dat het meest telt voor elk engineeringteam dat dacht dat --ignore-scripts hen tegen precies deze aanvalsklasse beschermde.

Eenmaal actief verzamelde de payload SSH-sleutels, cloudinloggegevens voor AWS, Google Cloud en Azure, Kubernetes-tokens, de inhoud van .env-bestanden en API-sleutels van AI-providers van elke machine waarop het vergiftigde pakket was geïnstalleerd. De gestolen data werd versleuteld met AES-256 en verzonden naar een typosquatting-domein dat eruitzag als een legitieme LiteLLM- of Trivy-bron, of rechtstreeks geüpload naar repositories op het eigen GitHub-account van het slachtoffer - een detail waardoor de operatie opging in normaal ogende ontwikkelaarsactiviteit in plaats van een duidelijke alarmering voor uitgaand verkeer te veroorzaken.

2.500 bedrijven, acht met naam geïdentificeerd in Europa en een gat van vijf maanden

CloudSEK publiceerde zijn onderzoek op 11 augustus 2026, vijf maanden na de compromittering in maart, en identificeerde meer dan 2.500 organisaties en ongeveer 434.000 CI/CD-pipelines als mogelijk blootgesteld - wat het bedrijf de grootste tot dusver in 2026 ontdekte AI-toeleveringsketeninbraak noemt. Tot de met hoge zekerheid geïdentificeerde treffers van CloudSEK behoren Siemens AG, Siemens Energy, Deutsche Bahn AG, Orange S.A., Vodafone Group Plc, London Stock Exchange Group, het Finse energiebedrijf Fortum Oyj en herverzekeraar Munich Re, verspreid over productie, telecom, spoor, financiën en verzekeringen in meerdere Europese jurisdicties.

CloudSEK stelt expliciet dat vermelding in zijn dataset geen automatisch bewijs is van een geslaagde inbraak - de bevinding betekent dat inloggegevens, domeinen, repositories of infrastructuur van die organisatie opdoken in de buitgemaakte data, en elke organisatie moet zelf onderzoeken of er sprake is van een reëel risico en wat er, indien iets, daadwerkelijk is buitgemaakt of misbruikt. Wat niet ter discussie staat is het gat van vijf maanden tussen de inbraak in maart en de openbaarmaking in augustus, een periode waarin elk van de genoemde organisaties op infrastructuur met gecompromitteerde inloggegevens kon hebben gedraaid zonder publieke waarschuwing dat de inbraak had plaatsgevonden.

Wat dit betekent voor iedereen die AI-infrastructuurtools draait

De FLASH-waarschuwing van de FBI van juli 2026 voegt een ongemakkelijk detail toe aan de tijdlijn: de in maart buitgemaakte inloggegevens worden maanden later nog steeds als reëel actief en bruikbaar beschouwd, en de dienst verwacht dat TeamPCP of gelieerde actoren ze zullen inzetten bij toekomstige, ongerelateerde inbraken in plaats van ze te laten verlopen. Voor elke organisatie die in maart 2026 LiteLLM-versie 1.82.7 of 1.82.8 in productie of CI draaide, is de juiste reactie niet wachten op individuele bevestiging van CloudSEK of LiteLLM - het is elke inloggegeven die die buildpipeline heeft aangeraakt als gecompromitteerd behandelen en nu roteren, vijf maanden te laat of niet.

De structurele les reikt verder dan LiteLLM. Elke organisatie die zijn CI-pipeline een security-tooling-dependency, zoals een scanner, laat ophalen zonder die vast te pinnen op een geverifieerde versie, heeft dezelfde opening die TeamPCP hier gebruikte, en --ignore-scripts is niet de bescherming die de meeste teams denken dat het is tegen een payload die via een .pth-bestand wordt afgeleverd. Europese security-verantwoordelijken die AI-infrastructuurtools draaien die op dezelfde opensource-toeleveringsketen zijn gebouwd, moeten dit minder zien als een LiteLLM-verhaal en meer als een reëel voorproefje van hoe de volgende AI-tooling-inbraak vermoedelijk zal worden afgeleverd.

Lees hierna: 141.006 testruns, drie echte inbraken  |  Micron: 2027 wordt krapper dan 2026