[tool.maturin]
data = "cook"Am 21. Oktober 2026 um 11:39:51 UTC veröffentlichte das Open-Source-LLM-Gateway LiteLLM die offizielle Version 1.107.0 auf PyPI. Im Quellcode-Repository war in der pyproject.toml lediglich diese eine unauffällige Konfigurationszeile hinzugefügt worden. Doch innerhalb der folgenden zwei Stunden verwandelte diese Änderung sämtliche Bereitstellungen ohne feste Versionsbindung in Credential-Harvesting-Knoten. Die Vertrauensgrenze moderner KI-Infrastruktur hat sich drastisch verschoben: vom einfachen Auditieren von Open-Source-Quellcode hin zum kompromisslosen Schutz von Build-Zugangsdaten. Und das Werkzeug, das den Angreifern die Torschlüssel aushändigte, war ausgerechnet der alltägliche KI-Programmierassistent der Entwickler.
Ein 12-Byte-Hook übernimmt den Interpreter – Ausführung ganz ohne Import
litellm==1.107.0 blieb auf PyPI bis 13:23 UTC aktiv – ein Zeitfenster von knapp zwei Stunden. Alle sieben veröffentlichten Wheels für Linux, macOS und Windows trugen die bösartige Nutzlast. Gleichzeitig wurden vier zentrale Tags auf Docker Hub und GHCR überschrieben: v1.107.0, latest, main-latest und main-stable. Zwischen 11:46:56 und 14:20 UTC verwiesen diese Tags geschlossen auf das manipulierte Image sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e. Jede automatisierte CI/CD-Pipeline, die Abhängigkeiten ohne exakte Versionsbindung bezog, schleuste die Backdoor direkt in ihre Produktionsumgebung ein.
Der bösartige Code gelangte über Maturins Direktive data = "cook" in das Verzeichnis purelib/ der Wheels. Nach der Paketinstallation wurden in site-packages drei Artefakte abgelegt: eine 12 Byte kleine cook.pth, eine 22.252 Byte große cook.py sowie die 25.509 Byte umfassende sitecustomize.py. Im offiziellen GitHub-Repository BerriAI/litellm existierte nie ein Ordner namens cook/, und auch das Quellcode-Archiv (sdist) enthielt diese Dateien nicht. Sicherheitsaudits, die ausschließlich öffentliche Commits auf GitHub prüfen, erwiesen sich gegenüber Injektionen zur Build-Zeit als vollkommen blind.
Die Datei cook.pth umfasst lediglich eine einzige Zeile: import cook. Gemäß dem Standardverhalten von Pythons .pth-Dateien führt der Interpreter beim Start automatisch alle Zeilen aus, die mit import beginnen. Die im selben Verzeichnis liegende sitecustomize.py fungiert ebenfalls als globaler Start-Hook und bildete zusammen mit der komprimierten Payload in cook.py eine doppelte Ausführungsgarantie. Die Angriffslast umgeht die reguläre Importkette vollständig: Selbst wenn auf einem System niemals import litellm aufgerufen wird, genügt bereits die Ausführung von pip oder der Start eines IDE-Sprachservers, um die Backdoor unmittelbar zu aktivieren.
Abbildung: Dateiinjektion und Ausführungskette der zweistufigen Nutzlast im manipulierten Paket LiteLLM 1.107.0. Quelle: SafeDep (Analysebericht zur Lieferkettensicherheit)
16 Spionagemodule nehmen KI-Toolchains und Gateway-Datenbanken ins Visier
Die Erststufen-Payload cook.py enthielt 16 dedizierte Datenerfassungsmodule, die das kompromittierte System lückenlos durchkämmten. Sie las private SSH-Schlüssel aus ~/.ssh/* und Shell-Verläufe aus und entschlüsselte in Chromium und Firefox gespeicherte Passwörter via DPAPI oder Master-Keys. Anschließend suchte die Schadsoftware gezielt nach Anmelde- und Konfigurationsdateien von AWS, Azure, GCP, ~/.kube/config, Docker, gh, Vault und Terraform. Darüber hinaus fragte sie AWS-IMDS-Metadatenendpunkte ab (zunächst IMDSv2, mit Fallback auf IMDSv1) und durchforstete /proc/<pid>/environ laufender Prozesse nach sensiblen Umgebungsvariablen. Das Arsenal war präzise auf die typische Workstation moderner Cloud-Native-Entwickler zugeschnitten.
Besonders aufschlussreich für die Absichten der Angreifer waren zwei Spezialmodule: ai_devtools und db_litellm. Das Modul ai_devtools durchsuchte das System gezielt nach Zugangsdaten von 17 verschiedenen KI-Entwicklungswerkzeugen, darunter Claude Code, Claude Desktop, Cursor, Windsurf, Copilot, VS Codes mcp.json, Gemini CLI, Codex, Continue, Aider, Zed und Hugging Face. Das Modul db_litellm wertete DATABASE_URL aus, um die Tabellen LiteLLM_CredentialsTable und LiteLLM_ProxyModelTable der Gateway-Datenbank vollständig zu exportieren. Ein KI-Gateway dient Unternehmen naturgemäß als zentraler Hub für Modell-Zugangsdaten. Fällt eine einzige LiteLLM-Instanz in feindliche Hände, erbeutet der Angreifer schlagartig sämtliche dahinter angebundenen API-Schlüssel der Upstream-Provider.
Die entwendeten Daten wurden mit einem zufällig generierten AES-256-CBC-Schlüssel verschlüsselt und anschließend über einen fest integrierten öffentlichen RSA-4096-Schlüssel mittels OAEP geschützt. Das resultierende tar.gz-Archiv wurde mit dem Header X-Token: XWiA8gZNa7NcX2XRoAEb an www.litellm.dev/healthcheck übermittelt. Die Zweitstufen-Payload sitecustomize.py sicherte sich über /tmp/remote_code_loader.lock ab und wandelte sich mittels fork() und setsid() in einen persistenten Hintergrund-Daemon um. Alle 3.600 Sekunden rief sie die Datei domain.txt aus dem GitHub-Repository letters9813/pythonclient-test ab, wiederholte den Spionagelauf und lud dynamisch ein Skript unter /codepy nach, das direkt via exec() ausgeführt wurde. GitHub sperrte das Konto letters9813 gegen 13:40 UTC, doch Systeme mit Internetverbindung hatten den Zweitstufencode zu diesem Zeitpunkt höchstwahrscheinlich bereits ausgeführt. Dank der täuschend echten Domain litellm.dev schlug herkömmliches Netzwerk-Monitoring innerhalb der zweistündigen Spanne keinen Alarm.
Drei gestohlene Entwickler-Schlüssel umgehen alle Kontrollschranken
Nach einem Sicherheitsvorfall im März hatte das Team von LiteLLM seine Release-Architektur massiv gehärtet. Build-Workflows wurden in private Repositories verlegt, Trusted GitHub Publishers aktiviert, Docker-Tags unveränderlich fixiert und Signaturen für Container-Images zwingend vorgeschrieben. Nach theoretischem Ermessen konnte kein Unbefugter mehr Release-Skripte verändern oder offizielle kryptografische Signaturen fälschen.
Die Protokolle vom 21. Oktober dokumentieren jedoch ein Eindringen mit gültigen Schlüsseln. Um 10:08:29 UTC blockierten GitHub-Branch-Protection-Rules eine Workflow-Änderung ohne vorangehenden Pull-Request-Review. Nur fünf Sekunden später, um 10:08:34 UTC, nutzte der Angreifer ein GitHub-CLI-Token mit Owner-Rechten der Organisation, um den Branch-Schutz gewaltsam zu deaktivieren, und übertrug den Commit 9cf97e935aeaf791b9c8db224a2bb3ee156134ce. Um 10:46:39 UTC bezog der manipulierte Workflow den Commit 20535d8fa aus dem Typosquatting-Repository Berri-AI/litellm (mit zusätzlichem Bindestrich gegenüber dem Original BerriAI) und bestand die Pre-Release-Prüfungen. Um 11:11:18 UTC segnete ein zweiter Entwickler-Account das Release-Gate für die Produktion ab. Nachdem die manipulierten Pakete um 11:53 UTC verteilt worden waren, löschte ein dritter Account sämtliche Workflow-Ausführungsprotokolle in Produktion und Pre-Release. Verfügt ein Angreifer über drei legitime Konten mit Höchstrechten, scheitern automatisierte Signaturen und Freigabeschranken nicht nur – sie versehen die Schadsoftware sogar mit dem offiziellen Echtheitssiegel.
Abbildung: Offizielle Sicherheitsmitteilung von LiteLLM zur Manipulation der Pipeline durch privilegierte Zugangsdaten am 21. Oktober. Quelle: LiteLLM (Offizieller Sicherheitsbericht)
Claude Code schrieb Token in Antworten – Öffentliche Logs wurden zum Hebel
Wie konnten die GitHub-Zugangsdaten dreier Kernentwickler überhaupt entwendet werden? Der offizielle Postmortem-Bericht von LiteLLM enthüllte ein entscheidendes Detail: Unter bestimmten Umständen bettete Claude Code das persönliche GitHub-CLI-OAuth-Token des Entwicklers direkt in den HTTP-Antworttext der API ein. War das KI-Gateway so konfiguriert, dass es vollständige Antwort-Payloads protokollierte, landeten diese privilegierten Bearer-Token im Klartext im LiteLLM-Logfile. Bei der anschließenden internen Untersuchung stieß das Team auf eine unauffällige, jedoch öffentlich über das Internet erreichbare LiteLLM-Instanz. Es gilt als gesichert, dass Angreifer über eine erst kürzlich geschlossene Sicherheitslücke in diese Instanz eindrangen und die GitHub-CLI-Tokens direkt aus den Protokolldateien entwendeten.
Dieses Ineinandergreifen von Schwachstellen löste in der Entwicklergemeinde intensive Grundsatzdiskussionen aus. Kritiker lokaler KI-Assistenten bemängelten, dass Entwickler-Agenten mit zu weitreichenden Host-Berechtigungen ausgestattet seien und die Weitergabe von CLI-Tokens an den Antwortstrom elementare Prinzipien der minimalen Rechtevergabe und Datenbereinigung verletze. Administratoren hielten dagegen, dass das Bereitstellen eines Gateways mit vollständiger Payload-Protokollierung im offenen Internet ein gravierender Konfigurationsfehler sei. Beide Perspektiven beschreiben dieselbe Realität: Entwickler programmieren Gateways mithilfe von KI-Assistenten, während der Assistent die Generalschlüssel in die Logs des Gateways schreibt. Die geschlossene Kette moderner KI-Tools vergrößert den Schadensradius eines einzelnen Fehlers dramatisch.
Erster Schritt der Bereinigung: Niemals pip ausführen und Versionen sperren
Für Teams, die Version 1.107.0 auf ihren Systemen installiert haben, enthält der offizielle Incident-Leitfaden eine unmissverständliche, wenngleich kontraintuitive Anweisung: Führen Sie keinesfalls pip install zur Reparatur aus. Da pip selbst ein Python-Prozess ist, löst dessen Aufruf cook.pth und sitecustomize.py erneut aus. Das korrekte Vorgehen erfordert, die Dateien cook.pth, cook.py, sitecustomize.py sowie die zugehörigen __pycache__-Ordner manuell direkt in site-packages zu löschen und anschließend verwaiste Hintergrundprozesse mit Zugriff auf /tmp/remote_code_loader.lock zu beenden. Erst nach dieser manuellen Bereinigung darf auf 1.106.2 zurückgegangen oder die gesamte Container- bzw. Virtualenv-Umgebung von Grund auf neu aufgebaut werden.
Das Löschen der Schad-Dateien stoppt lediglich den laufenden Angriff; die eigentliche Pflichtaufgabe ist der vollständige Austausch sämtlicher Zugangsdaten. Die Warnung der Entwickler ist eindeutig: „Wurde 1.107.0 auf einem Rechner mit ausgehender Internetverbindung installiert, muss davon ausgegangen werden, dass die Datenabwanderung erfolgreich war.“ Da Container-Neustarts oder automatische /tmp-Bereinigungen die Lockdateien entfernen, bedeutet das Fehlen einer Sperrdatei keineswegs Entwarnung. Betroffene Teams müssen Host-IAM-Rollen, Umgebungsvariablen, Datenbankkennwörter sowie jeden einzelnen in der Proxy-Datenbank hinterlegten Modell-API-Schlüssel unverzüglich rotieren und AWS-CloudTrail-Protokolle auf auffällige GetCallerIdentity-Aufrufe im fraglichen Zeitfenster prüfen. Die Versionen 1.106.2, 1.107.0rc1, 1.107.0rc2 sowie fest gebundene Installationen von litellm-proxy-extras==0.4.110 sind nachweislich sicher – ausschließlich Deployments mit ungebundenen Versionsangaben fielen dem zweistündigen Angriff zum Opfer.
Der Schwerpunkt bei Angriffen auf Software-Lieferketten hat sich verschoben. Angreifer investieren keine Monate mehr in unauffällige PRs; sie lesen Tokens aus ungesicherten Internet-Logs aus und lassen manipulierte Pakete durch offizielle Pipelines signieren. Wenn KI-Programmierassistenten tagtäglich sensible Zugangsdaten auf Entwicklerrechnern verarbeiten, sind die strikte Isolation von Gateway-Logs und das lückenlose Sperren aller Produktionsabhängigkeiten per Hashwert die einzigen wirksamen Schutzschilde für moderne KI-Infrastruktur.
Weiterführende Links:
- SafeDep-Analyse zur Lieferkettensicherheit: LiteLLM-PyPI-Kompromittierung und Backdoor-Analyse
- Offizieller LiteLLM-Sicherheitsbericht: Postmortem zum Sicherheitsvorfall vom 21. Oktober 2026
- Diskussion der Hacker-News-Community zur Manipulation von LiteLLM 1.107.0
