Ein Team bündelt seine Modellzugriffe über ein AI-Gateway, protokolliert Antworten zur Fehlersuche und automatisiert die Softwareverteilung. Jede dieser Entscheidungen kann sinnvoll sein. Gefährlich wird ihre Verbindung, wenn Zugangsdaten aus einer Agentensitzung in Logs landen und anschließend die Veröffentlichung vertrauenswürdig wirkender Software ermöglichen. Der neue LiteLLM-Vorfall zeigt, warum Unternehmen diese Übergänge gemeinsam prüfen sollten: vom Agentenkontext über Identitäten und Build-Artefakte bis zum Start einer Python-Umgebung.
Am 21. Oktober 2026 wurde LiteLLM 1.107.0 mit Schadcode über PyPI und Container-Registries verteilt. Die am 22. Oktober aktualisierten Analysen machen daraus mehr als eine Paketwarnung. Im Mittelpunkt stehen eine mutmaßliche Token-Leckage, missbrauchte Freigaben und Schadcode, der ohne ausdrücklichen LiteLLM-Import starten kann. Es handelt sich um einen neuen Vorfall, nicht um die erneute Aufbereitung des im März kompromittierten Releases. [1–4]
Betroffen ist das Artefakt, nicht nur die Versionsangabe
Laut Hersteller waren alle sieben PyPI-Wheels der Version 1.107.0 betroffen. Sie standen am 21. Oktober von 11:39:51 bis 13:23 Uhr UTC bereit. Auf Docker Hub zeigten die Tags v1.107.0, latest, main-latest und main-stable von 11:46:56 bis 14:20 Uhr UTC auf kompromittierte Images. Betroffene GHCR-Tags waren laut Hersteller bis 13:51 Uhr UTC nicht mehr verfügbar. Der private Enterprise-Releasekanal sei nicht betroffen gewesen. [1]
Für die eigene Untersuchung sollte deshalb der tatsächliche Bezugsweg zählen, nicht die Vertragskategorie. Ebenso sollten Teams Download, Installation und Ausführung getrennt rekonstruieren. Ein während des Angriffs gespeichertes Wheel kann später aus einem internen Cache installiert werden. Ein inzwischen korrigierter Container-Tag beantwortet nicht, welcher Digest gestern lief. Die Verfügbarkeitsfenster sind Suchhilfen, keine automatische Entwarnung für spätere Starts.
Wie aus Entwickleridentitäten eine offizielle Veröffentlichung wurde
LiteLLM beschreibt den Missbrauch von GitHub-Zugangsdaten dreier Entwickler. Ein privilegiertes Konto ermöglichte demnach das Umgehen von Branch-Schutzregeln. Die manipulierte Release-Pipeline wurde auf das ähnlich benannte Repository Berri-AI/litellm statt BerriAI/litellm gelenkt. Weitere kompromittierte Berechtigungen dienten der Freigabe und dem Löschen von Workflow-Aufzeichnungen. [1, 4]
Als vermuteten Ursprung nennt LiteLLM Logs einer öffentlich erreichbaren internen Gateway-Installation. In bestimmten Situationen habe Claude Code GitHub-CLI-OAuth-Tokens in Antwortinhalte aufgenommen; deren Protokollierung könne diese Tokens speichern. Der Hersteller vermutet, dass Angreifer sie dort erlangten. Wie sie zuerst in das interne Deployment gelangten, war im abgerufenen Bericht noch nicht bestätigt. Das ist eine Untersuchungshypothese, keine abschließend bewiesene Angriffskette. [1]
Die operative Schlussfolgerung lautet: Behandeln Sie Antwort-Logs eines Coding-Agenten wie potenziell sensible Daten. Prüfen Sie, ob dort Identitäten auftauchen können, die gleichzeitig Quellcodeverwaltung, Freigaben oder Veröffentlichung kontrollieren. Für die Risikobewertung ist diese Verbindung wichtiger als die Frage, welchem einzelnen Tool die Leckage zugeschrieben wird.
Warum ein sauberer Git-Tag nicht genügt
JFrog fand die zusätzlichen Dateien in den ausgelieferten Wheels, nicht im offiziellen Git-Tag. Auch das veröffentlichte Quellarchiv enthielt die drei Schadcode-Dateien nicht, obwohl dessen Build-Konfiguration eine auffällige Ergänzung aufwies. Ein Review des sichtbaren Bibliothekscodes konnte damit einen anderen Eindruck vermitteln als die Untersuchung des tatsächlich installierten Pakets. [2]
Für Unternehmen ergibt sich daraus eine konkrete Prüfanforderung: Geben Sie das Artefakt frei, das später produktiv eingesetzt wird. Dokumentieren Sie dessen Herkunft, Build-Identität, Hash und Dateiinventar. Prüfen Sie zusätzlich, ob der veröffentlichende Workflow seine Eingaben aus unerwarteten Repositorys beziehen darf. Eine gültige Signatur sollte dabei nicht als inhaltliches Sicherheitsurteil behandelt werden: Im beschriebenen Fall konnte gerade die manipulierte offizielle Pipeline signierte Schadartefakte erzeugen. [1, 2]
Der Python-Start wird zur Ausführungsgrenze
Die technischen Analysen identifizieren cook.pth, cook.py und sitecustomize.py im Wurzelverzeichnis von site-packages. Die erste Datei lädt den Credential-Stealer. Der zweite Startmechanismus soll einen abgekoppelten Prozess für später nachgeladenen Code erzeugen. Damit muss eine Anwendung LiteLLM nicht ausdrücklich importieren, um den Schadcode auszulösen. [2, 4]
Dieses Verhalten nutzt reguläre Python-Mechanismen: Die Python-Dokumentation beschreibt ausführbare Import-Zeilen in .pth-Dateien und das automatische Laden von sitecustomize. Entscheidend ist die betroffene Interpreter-Umgebung, nicht pauschal jeder Python-Prozess auf dem Rechner. Virtuelle Umgebungen und ihre Pfadkonfiguration gehören daher in die Analyse. [5]
JFrog weist außerdem auf Plattformunterschiede hin: Der Daemon-Pfad scheitert unter Windows an der verwendeten Fork-Funktion. Der Stealer-Pfad bleibt trotzdem relevant. Aus einer nicht funktionierenden Backdoor-Komponente folgt also keine generelle Entwarnung für Windows. [2]
Vom Paketbefund zum Identitätsvorfall
SafeDep beschreibt Sammelroutinen für Cloud-Zugangsdaten, SSH-Schlüssel, CI/CD-Secrets, Browserdaten und Authentifizierungsdateien von KI-Entwicklerwerkzeugen. Hinzu kommt der Versuch, Modellanbieter-Schlüssel aus einer erreichbaren LiteLLM-Proxy-Datenbank auszulesen. Diese Zielauswahl belegt zunächst Funktionen des Schadcodes, nicht den erfolgreichen Diebstahl jeder Datenkategorie bei jedem Betroffenen. [4]
Wiz berichtet jedoch auch über beobachteten Missbrauch gestohlener Cloud-Zugangsdaten: Rund viereinhalb Stunden nach der Exfiltration hätten Angreifer Rollenidentitäten geprüft und Modellangebote abgefragt. In wenigen Umgebungen seien zusätzliche IAM- und Kontoabfragen erfolgt. Das ist ein belastbareres Wirkungssignal als eine reine Downloadzahl, bleibt aber auf die beobachteten Umgebungen begrenzt. [3]
Für Enterprise-AI ist das der entscheidende Branchenkontext: Ein Gateway bündelt nicht nur Modellanfragen. Seine erreichbaren Identitäten und angeschlossenen Systeme bestimmen, wie weit ein kompromittiertes Paket wirken kann. Die Reaktion sollte deshalb Plattformbetrieb, Identitätsverwaltung, Entwicklung und Incident Response zusammenführen.
Was Unternehmen jetzt konkret prüfen sollten
Zuerst die Exposition rekonstruieren. Sichern Sie Build-Protokolle, Registry-Bezüge, Image-Digests und vorhandene Dateibefunde. Berücksichtigen Sie Entwicklergeräte, Notebook-Umgebungen, kurzlebige CI-Runner und interne Paketspiegel. Dokumentieren Sie ausdrücklich, welche historischen Daten fehlen.
Nicht unüberlegt den betroffenen Interpreter starten. LiteLLM warnt davor, mit einer gewöhnlichen Pip-Neuinstallation zu beginnen: Der Python-Start kann die Hooks erneut ausführen. Bevorzugen Sie nach der Beweissicherung einen Neuaufbau aus vertrauenswürdigen Quellen statt einer improvisierten Reparatur im laufenden System. Die dokumentierte vorläufige Ausweichversion ist 1.106.2; daraus folgt keine pauschale Aussage über sämtliche sonstigen Sicherheitsprobleme dieser Version. [1]
Identitäten getrennt bereinigen. Ermitteln Sie, welche Anbieter-, Datenbank-, Repository- und Cloud-Zugänge das betroffene System tatsächlich erreichen konnte. Widerrufen beziehungsweise erneuern Sie diese aus einer sauberen Umgebung. Prüfen Sie zusätzlich bereits laufende Sitzungen und temporäre Cloud-Berechtigungen. Ein ersetztes Container-Image entwertet keinen zuvor gestohlenen Schlüssel.
Für künftige Releases Grenzen setzen. Beschränken Sie Gateway-Logs auf notwendige Felder, trennen Sie Agentenzugänge von Veröffentlichungsrechten und erlauben Sie Build-Workflows nur festgelegte Quell-Repositorys. Verlangen Sie bei Änderungen dieser Grenzen eine gesonderte Freigabe. Testen Sie den gesamten Ablauf einschließlich Notfall-Widerruf, nicht nur den erfolgreichen Normalbetrieb.
Fazit: Nicht nur das Paket austauschen
Der Oktober-Vorfall verbindet drei überprüfbare Sicherheitsgrenzen: sensible Agentenausgaben, privilegierte Release-Identitäten und tatsächlich ausgelieferte Laufzeitdateien. Einzelne Details des Erstzugangs bleiben offen; eine Zuordnung zum früheren März-Angriff ist nicht belegt. [1, 2] Unternehmen sollten daher weder alle LiteLLM-Installationen pauschal für kompromittiert erklären noch nach einem Versionswechsel Entwarnung geben. Entscheidend sind die konkrete Artefakthistorie, eine saubere Wiederherstellung und die unabhängige Bereinigung erreichbarer Identitäten.
Quellen
- LiteLLM: Incident-Bericht vom 21. Oktober 2026, Stand 20:30 UTC
- JFrog Security Research: LiteLLM Hijacked Again, aktualisiert am 22. Oktober 2026
- Wiz Research: LiteLLM Compromised, Steals Credentials, aktualisiert am 22. Oktober 2026
- SafeDep: Analyse der kompromittierten LiteLLM-Wheels
- Python-Dokumentation: site und Startmechanismen