Nach Angaben von CloudSEK war LiteLLM kein direktes Ziel von TeamPCP. Die Kompromittierung ergab sich vielmehr als Folge des Trivy-Angriffs. Weil die Build-Pipeline von LiteLLM die kompromittierte Trivy-Version automatisch bezog, geriet der eigene Veröffentlichungsprozess in die Lieferkette der Angreifer. CloudSEK beschreibt die Kette so: Eine nicht widerrufene Zugangsberechtigung reichte aus, um drei Werkzeuge tief in das Ökosystem vorzudringen – von Trivy über das Build-System von LiteLLM bis zur eigentlichen Veröffentlichung.

Veröffentlicht wurden laut Bericht die Versionen 1.82.7 und 1.82.8 von LiteLLM auf PyPI. Der eingeschleuste Code wurde bei jedem Python-Aufruf ausgeführt, ohne dass Nutzer das Paket ausdrücklich importieren mussten. Die Schadfunktion lief damit auf allen Systemen, auf denen die betroffenen Versionen installiert waren.

Obwohl die manipulierten Pakete nach CloudSEK nur 40 Minuten lang verfügbar waren, genügte dieses Zeitfenster für eine breite Verbreitung. Das Unternehmen rekonstruiert daraus eine Exponierung von 434.000 CI/CD-Pipelines und mehr als 2.500 Organisationen. Auf der von CloudSEK geführten Liste finden sich unter anderem Nvidia, AWS, Samsung, Salesforce, Cisco, ServiceNow, Accenture Federal Services, Siemens, Regeneron Pharmaceuticals, London Stock Exchange Group, FedEx, Volkswagen, Orange, HP, Deutsche Bahn, NGINX und Zscaler.

Zugleich schränkt CloudSEK die Aussagekraft dieser Zahlen ein. Die Angaben zu mehr als 2.500 Unternehmen und 434.000 Pipelines beschrieben eine rekonstruierte Exponierung und seien nicht als Beleg zu lesen, dass jede aufgeführte Organisation erfolgreich kompromittiert wurde oder tatsächlich jede Zugangsberechtigung entwendet wurde. Ob es in einzelnen Fällen zu einer tatsächlichen Kompromittierung kam, müsse jeweils separat überprüft werden.

Als potenziell offengelegte Geheimnisse nennt CloudSEK unter anderem Zugangsdaten zum Veröffentlichen von Paketen, Cloud-Schlüssel, SSH-Schlüssel, Token, Umgebungsvariablen, Laufzeitdaten und Schlüssel von KI-Anbietern. Betroffen seien grundsätzlich alle Geheimnisse, auf die die LiteLLM-Bibliothek zugreifen konnte – also auch solche, die sich im Prozessspeicher befanden, in Jobs eingeschleust wurden, auf Datenträgern gespeichert waren oder sich über einen Metadatenservice einer Instanz abrufen ließen.

CloudSEK empfiehlt deshalb, alle potenziell kompromittierten Geheimnisse zu validieren und anschließend zusammen mit Dienstkonten und Sitzungen zu rotieren. Zudem sollten Protokolle ausgewertet werden, um Umfang und Zeitraum einer möglichen Exponierung zu bestimmen.

Für CloudSEK reicht die Bedeutung des Vorfalls über LiteLLM hinaus. Das Unternehmen erwartet, dass sich der nächste größere Lieferkettenangriff wahrscheinlich gegen KI-Infrastruktur richten wird, weil solche Systeme zu hochattraktiven Knotenpunkten zwischen Daten, Identitäten, Rechenressourcen und autonomen Aktionen geworden seien. Der Vorfall zeige nicht nur einen Bruch der Software-Lieferkette mit Bezug zu einem KI-Produkt, sondern auch, dass die Kompromittierung eines KI-Kontrollpunkts die umgebenden Identitäten und Systeme offenlegen könne.