Een LiteLLM supply chain aanval heeft dit jaar een flinke impact gehad: volgens CloudSEK zijn meer dan 2.500 organisaties en ruim 430.000 CI/CD-pijplijnen geraakt. De kern van het probleem zat niet in een directe aanval op LiteLLM zelf, maar in een keten van automatisering waarbij een gecompromitteerde component uiteindelijk doorwerkte naar downstream gebruikers.
Wat het extra zorgwekkend maakt, is dat het compromis zich via standaard ontwikkelstromen snel kon verspreiden en dat de “tijdsruimte” waarin het misging relatief kort was—maar alsnog groot genoeg om brede blootstelling te veroorzaken. Hieronder lees je hoe de aanval volgens CloudSEK in elkaar zat en welke stappen organisaties verstandig kunnen nemen.
Wat was de LiteLLM supply chain aanval?
CloudSEK rapporteert dat de aanval in de achtergrond ontstond als onderdeel van een bredere supply chain gebeurtenis. Kort nadat er eerder al problemen waren gecommuniceerd rondom Aqua Security’s Trivy (een open source vulnerability scanner), werd ook de LiteLLM-compromittering bekend. In de analyse van CloudSEK staat dat de LiteLLM-incidentstap een direct gevolg was van die eerdere Trivy-gerelateerde kwetsbare component.
Daarbij benadrukt CloudSEK dat de dreigingsactor—TeamPCP, bekend uit meerdere high-profile OSS-compromissen—niet specifiek op LiteLLM zou hebben gemikt. De besmetting ging volgens de rapportage vooral via de manier waarop build- en release-automatisering afhankelijkheden verwerkt.
De besmettingsketen: van Trivy naar LiteLLM
Volgens CloudSEK was de gecompromitteerde Python library en proxy server in LiteLLM terechtgekomen nadat een CI-pipeline automatisch een gemanipuleerde Trivy-versie installeerde. Door die automatische stap werden de build-artefacten vervolgens verder “meegenomen” in het releaseproces.
CloudSEK noemt daarbij expliciet twee LiteLLM-versies die op PyPI zijn gepusht: 1.82.7 en 1.82.8. Daarmee kregen aanvallers, zo stelt CloudSEK, toegang tot alle informatie die LiteLLM aanraakte in omgevingen waar die versies werden gebruikt.
CloudSEK vat het mechanisme in essentie samen als een keten die begint met één gecompromitteerde schakel—één niet ingetrokken token en drie gereedschappen diep—waardoor een klein credential-lek kan uitgroeien tot ecosysteem-brede blootstelling.
Waarom automatisering de impact vergroot
Een belangrijk punt uit de rapportage is dat geautomatiseerde buildsystemen “tijd comprimeren”. Zodra een kwaadaardig artefact eenmaal in een registry terechtkomt, kunnen volgende stappen het snel verder verspreiden: geplande jobs, dependency resolvers, tijdelijke runners, ontwikkelaarsmachines en zelfs gecachede componenten kunnen het besmette materiaal overnemen.
CloudSEK geeft daarmee aan dat de periode waarin je forensisch kunt reageren en credentials kunt roteren niet alleen beperkt is tot het moment waarop de gemanipuleerde package weer offline ging. Ook nadat een pakket is verwijderd, kan het kwaad al zijn overgenomen in omgevingen en workflows die eerder draaiden.
Wat deed de gemanipuleerde LiteLLM code?
De aangepaste LiteLLM-versies bevatten volgens CloudSEK kwaadaardige code die actief werd bij elke Python-invoking. Opmerkelijk detail: er was geen expliciete import nodig om de payload te laten draaien. Dat maakt het voor verdedigers lastiger om het gedrag te herkennen op basis van zichtbare import-statements of eenvoudige statische inspectie.
De payload zou volgens CloudSEK vervolgens draaien op alle systemen waar de package geïnstalleerd was. Dat betekent dat niet alleen de buildfase of alleen de CI-run relevant was, maar ook runtime-omgevingen waar de library werd gebruikt.
Hoe groot was de blootstelling volgens CloudSEK?
CloudSEK stelt dat de affected window in hun weergave slechts 40 minuten actief was. Toch was die korte tijdspanne voldoende om de propagatie binnen registries, workflows en afgeleide systemen op gang te brengen.
Als resultaat zijn 434.000 CI/CD-pijplijnen blootgesteld geraakt en zijn meer dan 2.500 organisaties betrokken—volgens CloudSEK gaat het hierbij om “gereconstrueerde exposure”. Dat is belangrijk: het is geen bewijs dat elke genoemde organisatie daadwerkelijk succesvol is gecompromitteerd of dat elke credential is gestolen.
CloudSEK vraagt daarom om per organisatie apart te verifiëren wat er precies is gebeurd. Cijfers geven de potentiële impact weer op basis van reconstructie, niet automatisch de feitelijke succesvolle aanval.
Welke organisaties werden genoemd?
CloudSEK’s lijst met namen is breed. In de rapportage worden onder meer Nvidia, AWS, Samsung, Salesforce, Cisco, ServiceNow, Accenture Federal Services, Siemens en Regeneron Pharmaceuticals genoemd. Ook andere partijen komen terug, zoals onder andere London Stock Exchange Group, FedEx, Volkswagen, Orange, HP, Deutsche Bahn, NGINX en Zscaler.
Bedrijfstammen in dit soort rapportages staan vaak op basis van “mogelijke” of “gereconstrueerde” blootstelling. Daarom blijft het cruciaal om niet alleen naar de naam op de lijst te kijken, maar vooral naar je eigen dependency- en secret-use historie.
Welke secrets konden worden blootgesteld?
Een van de meest directe gevolgen van de LiteLLM supply chain aanval was brede compromittering van gevoelige informatie. CloudSEK noemt onder andere:
- pakketpublicatie-credentials (zoals keys om releases te publiceren)
- cloud keys en tokens
- SSH-keys
- tokens, environment variables en runtime data
- AI-provider keys en andere toegangen die in de workflow of omgeving aanwezig waren
Met dergelijke gegevens kunnen aanvallers verschillende aanvallen uitvoeren: accounts overnemen, data stelen, kwaadaardige commits injecteren, persistentie opbouwen, lateraal bewegen binnen omgevingen, services verstoren, malware uitrollen en nog meer varianten toepassen.
Wat betekent dit praktisch voor jouw organisatie?
CloudSEK adviseert om niet te kijken naar “welke secrets denk je dat er gebruikt zijn”, maar breder: behandel in principe elke secret die door de LiteLLM library toegankelijk was als mogelijk gecompromitteerd. Dat omvat volgens CloudSEK secrets die:
- in process memory aanwezig waren
- werden geïnjecteerd in een job
- op disk zijn opgeslagen
- opvraagbaar waren via een instance metadata service
Met andere woorden: zelfs als je geen directe diefstal “ziet”, kan een gemanipuleerde component wel degelijk toegang hebben gehad.
Aanpak: valideren, roteren en onderzoeken
CloudSEK’s handelingslijn komt neer op drie sporen. Ten eerste: valideer of je daadwerkelijk exposure hebt gehad. Dat is vooral relevant als je hebt gewerkt met de getroffen LiteLLM-versies (1.82.7 en 1.82.8) of met workflows waarin die versie is verwerkt.
Ten tweede: roteer de mogelijk aangetaste secrets. Roteer niet alleen de technische sleutels, maar ook service accounts en sessies die met de betreffende omgeving gekoppeld waren.
Ten derde: check logs om het bereik en de tijdspanne van de exposure in te schatten. Daarmee bepaal je of de impact beperkt bleef tot een korte periode of dat er later nog vervolgactiviteiten zijn geweest.
Waarom dit incident ook een waarschuwing voor AI-infrastructuur is
CloudSEK trekt een bredere conclusie. De volgende grote supply chain aanval zal volgens hen waarschijnlijk gericht zijn op AI-infrastructuur, omdat die systemen een “knooppunt” zijn waar data, identiteit, compute en geautomatiseerde acties samenkomen.
Het incident laat volgens CloudSEK dus niet alleen zien dat een software supply chain breach ook een AI-product raakte, maar dat het compromis van een AI-controlepunt ook de systemen en identiteiten eromheen kan blootleggen. Daarmee ligt het risico niet uitsluitend bij één package, maar bij de plek waar de AI-stack aan andere processen hangt.
Gerelateerde incidenten en context
Supply chain aanvallen volgen vaak hetzelfde patroon: een gecompromitteerde stap in een keten wordt “automatisch” doorgegeven aan downstream tooling. Als je wilt kijken naar vergelijkbare mechanismen rond open source en buildstappen, is dit mogelijk interessant: Malicious LiteLLM en Trivy-hack: 3 stappen.
Ook bij andere ecosystemen zie je dat supply chain kwesties snel escaleren wanneer caches, registries en geautomatiseerde dependency resolvers meedoen. In dat licht kan bovendien een bredere supply chain kijk op governance en policies helpen bij het aanscherpen van je proces. Als je daarvoor referentie wilt, lees dan BdThemes supply chain aanval via JSON: wat je moet weten.
Conclusie: zie exposure als keten, niet als incident
De LiteLLM supply chain aanval toont hoe een gemanipuleerde component via een CI-pipeline kan doorwerken naar registratie, builds en uiteindelijk naar alle omgevingen waar de library wordt gebruikt. Zelfs wanneer de gemanipuleerde packages maar kort beschikbaar waren, kan automatisering de verspreiding versnellen.
Voor organisaties is de belangrijkste les: behandel mogelijke blootstelling systematisch. Identificeer welke versies en workflows betrokken waren, valideer per omgeving wat er echt is gebeurd, roteer verdachte secrets en onderzoek logs om de tijdlijn scherp te krijgen. Zo voorkom je dat een “korte” supply chain fout zich alsnog vertaalt naar langdurige gevolgen.
Bron: https://www.securityweek.com/over-2500-organizations-impacted-by-litellm-supply-chain-attack/
