Vierzig Minuten. Im März dieses Jahres genügte das, damit Angreifer routinemäßige Paketdownloads in einen massiven Datendiebstahl verwandelten.

Entwickler und Ingenieure, die dachten, sie luden legitime Releases der Open-Source-AI-Integrationsbibliothek LiteLLM (Versionen 1.82.7 und 1.82.8) herunter, erhielten stattdessen mit einer speicherscanenden Hintertür verseuchten Code. Nach Ausführung durchsuchte die schädliche Nutzlast den Arbeitsspeicher, erfasste dort gefundene Geheimnisse und sendete sie an von den Eindringlingen kontrollierte Server. Das Ergebnis: Viele Terabyte sensibler Daten wurden von einigen der weltweit größten Unternehmen exfiltriert.

Wie eine Paketkompromittierung zur globalen Lieferketten-Katastrophe wurde

Sicherheitsforscher entdeckten später ein Archiv mit insgesamt etwa 195 Terabyte. Darin fanden sich Cloud-Zugangsschlüssel, Container-Registry-Token, SSH-Schlüssel und aktive Datenbankpasswörter, die mehr als 2.500 Organisationen zugeordnet werden konnten. Der Datensatz enthielt außerdem Zugangsdaten aus über 434.000 CI/CD-Pipeline-Einträgen, viele davon aufgrund zu offener, öffentlicher Pipeline-Konfigurationen exponiert. Kurz gesagt: Sobald Zugangsdaten im Speicher oder in Pipeline-Variablen existierten, waren sie gefährdet.

Der Vorfall begann nicht bei LiteLLM. Den technischen Spuren zufolge, die Ermittler rekonstruierten, kompromittierten die Angreifer zunächst einen weit verbreiteten Schwachstellenscanner, Trivy, und nutzten diese Basis, um verwandte Projekte wie KICS und das Telnyx-Python-SDK zu vergiften. Von dort pflanzte sich die kontaminierte Kette in die veröffentlichten LiteLLM-Pakete fort.

Die Verantwortlichkeit für die Operation wurde von einer Gruppe mit dem Namen TeamPCP beansprucht. Mehrere unabhängige Sicherheitsteams bestätigten das Angriffs‑muster und die Zeitleiste, sodass kaum Zweifel bleiben, dass es sich um eine koordinierte Lieferketten-Kampagne und nicht um einen isolierten Exploit handelte.

Wer betroffen war? Das Ausmaß ist groß. Technologie-Giganten und Unternehmen aus der kritischen Infrastruktur tauchen in den Veröffentlichungen auf: Nvidia, Amazon Web Services, Samsung, Cisco, Siemens, Volkswagen, Reuters, FedEx, Epic Games, X (ehemals Twitter), HP, Philips und Deutsche Bank gehören zu den Firmen, deren exponierte Schlüssel mit hoher Sicherheit bestätigt wurden.

Warum eskalierte das so schnell? Zwei Gründe trafen aufeinander: die Eile bei der Einführung von AI-Tools und ein fragiles Vertrauensmodell in Open-Source-Lieferketten. Organisationen, die eilig AI-Funktionalitäten integrieren wollten, installierten Bibliotheken und Automatisierungs‑Pipelines oft mit minimaler Prüfung. In Umgebungsvariablen abgelegte Geheimnisse oder in Build-Runnern verbliebene Tokens wurden zur leichten Beute.

Es gibt auch einen technischen Grund für die hohe Effizienz des Angriffs. Die bösartigen LiteLLM-Builds führten einen Memory-Scraper aus, der im Arbeitsspeicher befindliche Zugangsdaten auswarf und an einen Collector sendete. Das bedeutete, dass selbst kurzlebige Tokens, die während Deployments nur vorübergehend verwendet wurden, erfasst wurden. Kurzlebig heißt nicht sicher, wenn ein Angreifer den RAM auslesen kann.

Sperren und ersetzen Sie sofort alle offengelegten Schlüssel und Token.

Diese eine dringende Anweisung wird derzeit von Sicherheitsteams wiederholt. Die Bereinigung ist jedoch kompliziert. Da viele geleakte Geheimnisse ohne Domänenkennzeichnungen oder Organisationshinweise beobachtet wurden, stehen Verteidiger vor einer schmerzhaften Inventarisierungsaufgabe: feststellen, welche Schlüssel zu welchen Diensten gehören, dann sperren, rotieren und neu konfigurieren. Für viele Engineering‑Teams bedeutet das den Wiederaufbau von CI/CD-Runnern, das Ersetzen eingebetteter Geheimnisse durch kurzlebige Anmeldeinformationen und die Einführung von Secret-Scanning‑Tools, die Lecks erkennen, bevor sie in Produktion gelangen.

Die Lehren sind klar und hart. Erstens: Die Herkunft von Abhängigkeiten zählt. Das übereilte Installieren praktischer Bibliotheken ohne Überprüfung von Checksummen und Publisher-Identitäten schafft Lieferketten-Risiken. Zweitens: Geheimnisse sollten nicht im Klartext in Pipeline-Variablen oder in langlebigen Tokens leben. Verwenden Sie kurzlebige Service-Identitäten und zugriffsbasierte Workload-Authentifizierung, wo möglich. Drittens: Das Open-Source-Ökosystem braucht stärkere Schutzmechanismen: reproduzierbare Builds, signierte Pakete und bessere Publisher-Hygiene können diese Angriffsart abschwächen.

Für Organisationen, die LiteLLM oder damit verbundene Tools nutzen, sollten sofortige Maßnahmen u. a. beinhalten:

  • Führen Sie eine Inventarisierung aller Zugangsdaten und Token durch, die möglicherweise in Build‑ oder Laufzeit‑Speicher geladen wurden.
  • Sperren und rotieren Sie diese Schlüssel und geben Sie neue Anmeldeinformationen mit dem Prinzip der minimalen Rechtevergabe aus.
  • Prüfen Sie CI/CD-Pipelines und ersetzen Sie Klartext-Geheimnisse durch treuhandgestützte, kurzlebige Tokens.
  • Validieren Sie Paketintegrität, indem Sie Checksummen prüfen und signierte Releases vertrauenswürdiger Maintainer bevorzugen.
  • Überwachen Sie ausgehenden Verkehr von Build-Infrastrukturen auf Anomalien, die auf verbleibende Hintertüren hinweisen könnten.

Der Angriff ist ein Weckruf. Die Integration von AI-Tools kann erhebliche Produktivitätsgewinne bringen. Wenn Schnelligkeit jedoch die Sicherheit überholt, sind die Folgen real. Zugangsdaten sind Währung. Einmal geleakt, ermöglichen sie Eskalation, laterale Bewegung und Datendiebstahl in großem Umfang. Teams müssen davon ausgehen, dass Kompromittierungen möglich sind, und Systeme so gestalten, dass ein Angreifer in einer einzigen Sitzung nur begrenzt erbeuten kann.

Erwarten Sie weitere detaillierte Offenlegungen von Sicherheitsfirmen, während sie den 195-Terabyte‑Schatz weiter auswerten und betroffene Organisationen kartieren. Bis dahin ist die sicherste Haltung eine schnelle, koordinierte Schlüsselrotation in Kombination mit einer forensischen Überprüfung von Build- und Deploy‑Prozessen.