Manipulierte LiteLLM-Versionen auf PyPI: Angriff saugt in Minuten Tausende Zugangsdaten aus KI-Teams ab

Zwei präparierte Versionen der Python-Bibliothek LiteLLM haben gezeigt, wie schnell ein Angriff auf die Software-Lieferkette („Supply Chain“) ganze Entwicklungsumgebungen kompromittieren kann. LiteLLM dient vielen KI-Teams als zentrale Schnittstelle, um verschiedene Sprachmodelle über eine einheitliche Programmierschnittstelle anzusprechen – und sitzt damit oft an einer sensiblen Stelle in internen Anwendungen und Automatisierungen.

Die kompromittierten Ausgaben wurden kurzzeitig über das Python Package Index (PyPI) verteilt, dem Standard-Repository für Python-Pakete. Wer in dieser Zeit routinemäßig Abhängigkeiten aktualisierte – etwa per „pip install -U“ –, konnte sich unbemerkt Schadcode ins System holen. Als derzeit unauffällige Referenzversion gilt nach den vorliegenden Analysen LiteLLM 1.82.6.

Der Vorfall wird einer Gruppe zugeschrieben, die unter dem Namen „TeamPCP“ geführt wird und bereits mit weiteren jüngeren Kompromittierungen in Verbindung gebracht wurde. Der Fall ist auch für deutsche Unternehmen relevant: Python ist in Data-Teams, KI-Projekten und CI/CD-Pipelines (automatisierte Build- und Auslieferungsstrecken) weit verbreitet – und damit ein attraktives Einfallstor.

Manipulierte Releases 1.82.7 und 1.82.8: 47.000 Downloads in 46 Minuten

Betroffen waren nach bisherigen Erkenntnissen die LiteLLM-Versionen 1.82.7 und 1.82.8. Beide wurden auf PyPI veröffentlicht und nach Entdeckung wieder entfernt. Entscheidend ist die Dynamik: Sobald Angreifer die Möglichkeit haben, unter dem Namen eines etablierten Projekts zu veröffentlichen, reichen Minuten – und die Installationen folgen automatisiert.

Öffentlich einsehbare Downloadzahlen deuten auf eine enorme Verbreitung in kürzester Zeit hin: Rund 47.000 Downloads sollen innerhalb von 46 Minuten erfolgt sein. Solche Werte sind schwer zu interpretieren, weil ein Download etwa in einem CI-Runner, einem gemeinsamen Server oder einem Docker-Image landen kann, das anschließend vielfach repliziert wird. zeigt die Zahl, wie schnell sich Schadcode über Abhängigkeits-Repositories verbreiten kann.

LiteLLM ist dabei kein Randpaket: Es wird häufig als „Gateway“ eingesetzt, das Anwendungen mit mehreren Modellanbietern verbindet. Wer diese Bibliothek kompromittiert, trifft nicht nur einzelne Entwicklerrechner, sondern potenziell auch Cloud-Umgebungen, Cluster und automatisierte Deployments – dort, wo oft weitreichendere Berechtigungen hinterlegt sind.

Endor Labs: Infostealer sammelt Schlüssel, Tokens und.env-Dateien

Sicherheitsforscher – unter anderem von Endor Labs – beschreiben den Schadcode als mehrstufigen „Infostealer“. In der ersten Phase sucht er gezielt nach verwertbaren Geheimnissen: SSH-Schlüssel, Passwörter, Cloud-Zugangsdaten, Kubernetes-Tokens sowie Inhalte aus.env-Dateien. Auch Wiederherstellungsphrasen von Krypto-Wallets sollen im Fokus gestanden haben.

In der zweiten Phase werden die Daten verschlüsselt an eine Infrastruktur der Angreifer übertragen. Gerade in Entwicklungsumgebungen kann solcher Datenverkehr unauffällig bleiben, weil Systeme ohnehin regelmäßig externe Verbindungen aufbauen – etwa zu Paketquellen, Programmierschnittstellen oder Artefakt-Repositories. Angreifer nutzen dieses „Grundrauschen“ aus, zumal viele Entwicklergeräte und Build-Runner nicht engmaschig netzwerkseitig überwacht werden.

Die dritte Phase dient der Persistenz: Der Schadcode richtet laut Analyse eine Hintertür ein, getarnt als Systemdienst mit dem Namen „System Telemetry Service“. Das wirkt wie ein legitimer Baustein für Systembeobachtung – und kann in Umgebungen ohne saubere Inventarisierung installierter Dienste lange unentdeckt bleiben.

tückisch: In Version 1.82.8 soll zusätzlich eine.pth-Datei genutzt worden sein, um die Schadfunktion bei jedem Start von Python auszulösen – selbst wenn LiteLLM anschließend gar nicht aktiv verwendet wird. Damit reicht unter Umständen schon ein kurzer Testlauf, um eine dauerhafte Ausführung zu riskieren.

Wie die Angreifer an PyPI-Veröffentlichungsrechte kamen

Der Angriff folgt einem Muster, das in der Branche seit Jahren als gefährlich gilt: Nicht die Anwendung selbst ist das erste Ziel, sondern die Werkzeuge und Prozesse, mit denen Software gebaut und veröffentlicht wird. LiteLLM soll in seiner Pipeline das Sicherheitswerkzeug Trivy genutzt haben – offenbar ohne feste Versionsbindung („nicht gepinnt“). Wird in so einem Setup eine Abhängigkeit kompromittiert, kann das die gesamte Toolchain infizieren.

Nach dem beschriebenen Ablauf führte die Ausführung einer kompromittierten Komponente in der Pipeline dazu, dass ein geheimer Schlüssel offengelegt wurde, mit dem sich Pakete im Namen des LiteLLM-Projekts auf PyPI veröffentlichen lassen. Mit einem solchen Schlüssel sprechen Angreifer gegenüber dem Repository faktisch „mit der Stimme“ des Projekts – inklusive des Vertrauens, das Nutzer in die Quelle setzen.

Der Kern des Problems ist damit weniger ein klassischer Programmfehler als eine Verkettung riskanter Praktiken: fehlende Versionsfixierung, zu breit verfügbare Geheimnisse in Build-Umgebungen und implizites Vertrauen in Drittwerkzeuge. In deutschen Unternehmen finden sich ähnliche Muster – etwa wenn CI-Jobs mehr Rechte besitzen als nötig oder Umgebungsvariablen mit Schlüsseln zu großzügig in Logs und Subprozesse durchgereicht werden.

Hinzu kommt ein Täuschungsmanöver, das Detektion erschwert: Die Angreifer registrierten Domains, die legitime Infrastruktur nachahmen sollten, darunter „models.litellm.cloud“. Solche „Lookalike“-Ziele können Filter umgehen, wenn Teams Netzwerkziele nicht strikt validieren oder nur auf erwartete Domainlisten setzen.

Warum der Schaden CI/CD und Cloud-Umgebungen treffen kann

LiteLLM wird laut den im Artikel genannten Zahlen in großem Stil genutzt: mehr als drei Millionen Downloads pro Tag und rund 95 Millionen in 30 Tagen. Selbst wenn nur zwei Versionen manipuliert waren, ist die potenzielle Reichweite groß – gerade in KI-Projekten, in denen Abhängigkeiten häufig aktualisiert werden.

Das größte Risiko liegt nicht beim einzelnen Entwicklerrechner, sondern in automatisierten Umgebungen: CI/CD-Runner, Datenverarbeitungsjobs, Docker-Images und gemeinsam genutzte Notebooks. Wird dort eine kompromittierte Version installiert, kann sie sich durch regelmäßige Image-Neubauten und wiederkehrende Jobs schnell vervielfältigen – und dabei auf wertvolle Geheimnisse zugreifen, etwa Deployment-Schlüssel oder Kubernetes-Zugänge.

Die gesammelten Daten sind genau die „Sprungbretter“, die Angreifer für seitliche Bewegungen in Netzen benötigen: Ein gestohlener SSH-Schlüssel kann den Zugang zu Bastion-Hosts öffnen, ein Kubernetes-Token Kontrolle über Cluster ermöglichen, und eine.env-Datei kann API-Schlüssel für kostenpflichtige KI-Dienste enthalten. Die Folgen reichen von Datenabfluss bis zur Übernahme von Infrastruktur – inklusive finanzieller Schäden durch missbrauchte Cloud- und API-Ressourcen.

Teilweise ist von rund 500.000 Exfiltrationsereignissen oder infizierten Geräten die Rede, ohne unabhängige Bestätigung. Die Zahl sollte daher vorsichtig bewertet werden – sie unterstreicht aber, welche Größenordnung solche Supply-Chain-Vorfälle erreichen können, selbst wenn nur ein kurzer Veröffentlichungszeitraum betroffen ist.

Was jetzt zu tun ist: 1.82.6 als Referenz – und Secrets konsequent rotieren

Als derzeit „saubere“ Version wird LiteLLM 1.82.6 genannt. Wer 1.82.7 oder 1.82.8 installiert hat, sollte nicht nur zurückwechseln, sondern den Vorfall wie einen vollständigen Sicherheitsincident behandeln. Denn: Dass die manipulierten Pakete von PyPI entfernt wurden, bedeutet nicht, dass betroffene Systeme automatisch bereinigt sind.

Operativ heißt das: Alle Installationen der Versionen 1.82.7 und 1.82.8 identifizieren – auf Entwicklerrechnern ebenso wie auf CI-Runnern, Servern und in Container-Images. Danach auf 1.82.6 zurückgehen und parallel davon ausgehen, dass Geheimnisse abgeflossen sein könnten. Entsprechend müssen Schlüssel und Tokens widerrufen und neu ausgestellt werden, für Cloud-Konten, Kubernetes, SSH und Veröffentlichungstokens.

Für Unternehmen ist der Vorfall auch ein Weckruf im Umgang mit PyPI und ähnlichen Ökosystemen: Ein Repository ist kein „sicherer App-Store“, sondern ein Verteiler, dessen Vertrauenskette an Build-Prozessen, Signaturen, Integritätsprüfungen und sauberer Rechtevergabe hängt. Mittelfristig sprechen solche Fälle für strengere Standards – feste Versionsbindungen, interne Spiegelserver, Integritätskontrollen und eine engere Überwachung ausgehender Verbindungen von Build-Runnern. Das ist aufwendig, aber oft günstiger als ein einziger erfolgreicher Supply-Chain-Angriff.