LiteLLM: Supply-Chain-Angriff legt Zugangsdaten von Tausenden Organisationen offen

Auf PyPI veröffentlichte Schadversionen

Ein Supply-Chain-Angriff auf LiteLLM, ein Open-Source-Gateway für Anwendungen auf Basis künstlicher Intelligenz, soll zur Verbreitung der Backdoor SANDCLOCK und zur Offenlegung zahlreicher Zugangsdaten geführt haben.

Der Angriff wird der Gruppe TeamPCP zugeschrieben. Den bisherigen Erkenntnissen zufolge soll sie die Zugangsdaten der Projektadministratoren erbeutet haben. Anschließend sollen die Angreifer die kompromittierten Versionen 1.82.7 und 1.82.8 auf PyPI hochgeladen haben. Die Veröffentlichungen erfolgten offenbar um März 2026.

Der Zeitraum der möglichen Kompromittierung könnte sich somit über mehrere Monate erstreckt haben. Einige Organisationen haben möglicherweise noch nicht erkannt, dass die manipulierte Komponente installiert oder die gestohlenen Zugangsdaten anschließend verwendet wurden.

LiteLLM wird als Bibliothek und Integrationsschicht eingesetzt, um Anfragen an mehr als hundert Anbieter großer Sprachmodelle weiterzuleiten. Dazu gehören OpenAI, Anthropic, Google Gemini sowie lokal über Ollama verwaltete Modelle.

Die Kompromittierung einer Komponente, die in automatisierten Pipelines eingesetzt wird, kann die Angriffsfläche erheblich vergrößern. Es ist nicht erforderlich, jedes Unternehmen direkt anzugreifen: Es genügt, Schadcode in ein Element einzuschleusen, das von zahlreichen Anwendungen und Entwicklungsprozessen gemeinsam genutzt wird.

SANDCLOCK und der mögliche Weg der Zugangsdaten

Das verfügbare Briefing bezeichnet SANDCLOCK als Backdoor, macht jedoch keine Angaben zu ihrer internen Funktionsweise. Auch ist nicht bekannt, welche Daten sie direkt sammelt oder an welche Infrastruktur sie diese übermittelt.

Besonders relevant ist die Einsatzumgebung von LiteLLM. Die Software kann in Entwicklungsumgebungen, CI/CD-Systemen, Automatisierungswerkzeugen und Diensten ausgeführt werden, die sich bei Cloud- oder KI-APIs authentifizieren müssen.

Unter diesen Bedingungen kann ein manipuliertes Paket auf Umgebungsvariablen, Konfigurationsdateien und in Pipelines verwendete Secrets zugreifen. Potenziell offengelegte Zugangsdaten umfassen:

• Schlüssel für AWS, GCP und Firebase;
• Tokens für Registries wie Amazon ECR und JFrog;
• persönliche GitHub-Zugriffstokens beziehungsweise PATs;
• private Schlüssel von GitHub Apps;
• SSH-Zugangsdaten;
• Secrets von Kubernetes-Clustern;
• Signaturpasswörter;
• API-Schlüssel für KI-Dienste, darunter Schlüssel von OpenAI und Anthropic.

Ein solcher Zugriff kann das Lesen oder Verändern von Repositories, die Manipulation von Build- und Deployment-Pipelines, den Zugriff auf Image- oder Paket-Registries sowie Eingriffe in Cloud-Infrastrukturen ermöglichen. Bei weitreichenden Berechtigungen kann sich das Risiko auch auf Kubernetes-Cluster und die darin betriebenen Dienste erstrecken.

Ob alle erfassten Zugangsdaten für weitere Aktivitäten verwendet wurden, ist nicht bekannt. Bereits die mögliche Offenlegung erfordert jedoch den Widerruf und Austausch der Secrets. Es reicht nicht aus, lediglich anzunehmen, dass ein Schlüssel nicht missbraucht wurde.

Umfang der Offenlegung

Resecurity hat ein 150 GB großes Archiv analysiert, das der Aktivität von TeamPCP zugeschrieben wird. Darin sollen die Manifeste owners.txt und repos.txt 898 unterschiedliche GitHub-Eigentümer aus Organisationen und Einzelkonten sowie 2.038 Repositories aufführen.

Die Kompromittierung ist fragmentiert: 631 Eigentümer sollen jeweils nur ein Repository in der Liste haben. Die meisten betroffenen Repositories soll Cencosud-Cencommerce mit 64 aufweisen.

Zu den aufgeführten Namen gehören Microsoft, Azure, IBM, NVIDIA, PayPal (Zettle), Deloitte, Bosch, S&P Global, Elevance Health, 84.51° (Kroger), Adeo (Leroy Merlin), Kärcher, Dräger, ID.me und 1inch.

Resecurity erfasste anhand der Schlüsselnamen 2.146 Datensätze. Die Werte sollen über die strukturelle Maskierung hinaus nicht untersucht worden sein. Die Zahl bezeichnet daher die im Archiv identifizierten Elemente und nicht zwingend noch gültige oder erfolgreich verwendete Zugangsdaten.

Den bisherigen Erkenntnissen zufolge soll der Vorfall mehr als 2.500 Organisationen und Hunderttausende CI/CD-Umgebungen betroffen haben. Die Differenz zwischen der Gesamtzahl der Organisationen und den aufgeführten GitHub-Eigentümern kann auf die Struktur der analysierten Daten und die verwendeten Erfassungskriterien zurückzuführen sein.

Technologie, Finanzen und Gesundheitswesen unter den betroffenen Branchen

Am stärksten vertreten ist der Bereich Technologie und Software, in dem Open-Source-Werkzeuge und automatisierte Pipelines besonders häufig eingesetzt werden.

Es folgen Banken, Finanz- und Versicherungsunternehmen sowie Gesundheitswesen, Pharmaindustrie und Medizintechnik. Die Beteiligung regulierter Organisationen erhöht die Bedeutung des Vorfalls: Eine Kompromittierung kann die Betriebskontinuität, den Datenschutz und die Einhaltung von Anforderungen an das Zugriffsmanagement beeinträchtigen.

Weitere identifizierte Branchen sind:

1. Einzelhandel und E-Commerce;
2. Medien, Gaming und Adtech;
3. Fertigung und Industrie;
4. professionelle Dienstleistungen;
5. Cybersicherheit;
6. Kryptowährungen;
7. öffentliche Verwaltung.

Das konkrete Risiko hängt von den LiteLLM zugewiesenen Berechtigungen und den Pipelines ab, in denen das Paket installiert wurde. Eine isolierte Testumgebung hat nicht dieselben Auswirkungen wie ein CI/CD-Runner, der Images veröffentlichen, Infrastrukturen aktualisieren oder Anwendungen in der Produktion bereitstellen darf.

Der Angriff kann außerdem die Zeit bis zur Entdeckung des Vorfalls verlängern. Die Malware könnte in zahlreichen Umgebungen mit unterschiedlichen Konfigurationen ausgeführt worden sein. Dadurch wird die Korrelation von Ereignissen erschwert und sowohl die MTTD (Mean Time to Detect) als auch die MTTR (Mean Time to Respond and Recover) können steigen.

Sofort einzuleitende Prüfungen

Organisationen, die LiteLLM installiert haben, sollten das Vorhandensein der Versionen 1.82.7 und 1.82.8 in Projekten, Container-Images, Paketmanager-Caches und CI/CD-Runnern prüfen. Auch indirekte Installationen über Abhängigkeiten oder vorkonfigurierte Images müssen berücksichtigt werden.

Bei einem Treffer oder bestehenden Zweifeln sollte die Reaktion Folgendes umfassen:

• Widerruf und Neugenerierung der privaten Schlüssel von GitHub Apps;
• Austausch der PATs und GitHub-Tokens;
• Rotation der AWS-, GCP- und Firebase-Zugangsdaten;
• Widerruf der ECR- und JFrog-Tokens;
• Austausch der SSH-Schlüssel;
• Änderung der Signaturpasswörter;
• Neugenerierung der API-Schlüssel für KI-Anbieter;
• Ungültigmachung aktiver Sitzungen.

Die Rotation sollte mit Administratorkonten und Secrets beginnen, die in Build- und Deployment-Prozessen verwendet werden. Die neuen Werte sollten nicht in noch ungeprüfte Pipelines eingetragen werden.

Anschließend müssen GitHub-Logs, CI/CD-Runner, Registries, Cloud-Anbieter und Kubernetes-Cluster analysiert werden. Dabei ist nach ungewöhnlichen Zugriffen, der Erstellung von Tokens, Änderungen an Workflows, neuen SSH-Schlüsseln, unerwarteten Veröffentlichungen von Paketen oder Images sowie Deployments zu suchen, die keinem regulären Bediener zugeordnet werden können.

Es liegen keine Hinweise darauf vor, dass der Vorfall in den KEV-Katalog der CISA aufgenommen wurde oder eine entsprechende Frist zur Abhilfe besteht. Ebenso ist kein zugehöriger CVE-Identifier bekannt.

Wer LiteLLM im betroffenen Zeitraum installiert hat, sollte alle in der Umgebung vorhandenen Zugangsdaten als potenziell offengelegt behandeln – auch wenn bislang keine unmittelbaren Anzeichen eines Missbrauchs vorliegen. Die Kompromittierung einer Softwareabhängigkeit kann noch lange nach der Veröffentlichung des Schadpakets Spuren in nachgelagerten Systemen hinterlassen.