Manipulierte LiteLLM-Version über PyPI und Docker verteilt
Unbekannte Angreifer haben den Release-Prozess des Open-Source-KI-Gateways LiteLLM kompromittiert. Die manipulierte Version 1.107.0 gelangte über PyPI, Docker Hub und die GitHub Container Registry in die öffentliche Verteilung.
PyPI stellte das Paket nach wenigen Stunden unter Quarantäne. Die zugehörigen Container-Images wurden ebenfalls entfernt. Entscheidend ist jedoch nicht, ob die Version heute noch abrufbar ist, sondern ob sie bereits installiert und anschließend Python ausgeführt wurde.
LiteLLM stellt eine einheitliche Schnittstelle für verschiedene LLM-Anbieter bereit. Das Projekt kommt laut den vorliegenden Angaben auf rund 23 Millionen Downloads pro Woche. In Unternehmensumgebungen läuft das Gateway häufig direkt neben API-Schlüsseln, Cloud-Identitäten und Datenbankzugängen.
| Merkmal | Angabe |
|---|---|
| Manipulierte Version | 1.107.0 |
| Letzte bekannte sichere Version | 1.106.2 |
| Upload der Schadversion | Mittwoch, 11:39 UTC |
| Verbreitungswege | PyPI, Docker Hub und GHCR |
| Reichweite des Projekts | Rund 23 Millionen Downloads pro Woche |
| Abfrageintervall des RAT | Eine Stunde |
Infostealer sucht gezielt nach wertvollen Schlüsseln
Die Schadsoftware besteht aus den drei Dateien cook.pth, cook.py und sitecustomize.py. Die Datei cook.pth sorgt dafür, dass cook.py automatisch beim Start des Python-Interpreters ausgeführt wird. Eine zusätzliche Benutzeraktion ist dafür nicht erforderlich.
Der Infostealer umfasst 16 Module. Er sucht unter anderem nach API-Schlüsseln für OpenAI, Anthropic und Cohere sowie nach Zugangsdaten für AWS, Google Cloud und Microsoft Azure. Hinzu kommen Browser-Cookies, gespeicherte Browser-Zugangsdaten, SSH-Schlüssel, GPG-Schlüssel und Shell-Verläufe.
Für den Datenabfluss verschlüsselt die Schadsoftware die gesammelten Informationen mit AES-256-CBC. Der verwendete Schlüssel wird zusätzlich mit RSA-4096 geschützt. Anschließend werden die Daten per HTTP-POST an http://www[.]litellm[.]dev/healthcheck übertragen.
Gestohlene API-Schlüssel sind nicht nur ein Datenschutzproblem. Sie können auch unmittelbar hohe Nutzungskosten verursachen, wie der Fall der entwendeten OpenCode-Zugangsdaten gezeigt hat.
Remote-Access-Trojaner ermöglicht beliebigen Code
Mit sitecustomize.py enthält das Paket zusätzlich einen Remote-Access-Trojaner. Ein solcher RAT ermöglicht Angreifern die Fernsteuerung eines kompromittierten Systems. Die Datei wird ebenfalls beim Start von Python geladen und richtet einen Hintergrundprozess ein.
Dieser Prozess fragt die Infrastruktur der Angreifer stündlich nach neuen Befehlen ab. Dadurch kann auf betroffenen Rechnern und Containern beliebiger Code nachgeladen und ausgeführt werden. Eine reine Rotation einzelner LLM-Schlüssel reicht deshalb nicht aus.
Socket-Forscher erklärten sinngemäß, dass Teams mit Version 1.107.0 die Verteilung sofort stoppen und alle Umgebungen untersuchen sollten, in denen Python nach der Installation lief. Dazu gehören insbesondere Proxy-Container und CI-Runner.
Hinweise auf kompromittierte Systeme
Aikido Security, Wiz und Socket haben Indikatoren für die Suche nach betroffenen Installationen veröffentlicht. Besonders relevant sind Dateien unter /tmp, die auf einen bereits erfolgten Datenabfluss oder einen gestarteten Fernzugriff hindeuten.
| Indikator | Bedeutung |
|---|---|
/tmp/.pc_once_* | Der Datenabfluss wurde wahrscheinlich bereits ausgelöst |
/tmp/remote_code_loader.lock | Der Befehlsdaemon lief oder läuft noch |
litellm/litellm:1.107.0 | Direkt betroffenes Container-Image |
latest, main-latest, main-stable | Möglicherweise betroffene, nicht fest auf eine Version gesetzte Tags |
Betroffene Systeme sollten isoliert, forensisch untersucht und aus einem bekannten sicheren Stand neu aufgebaut werden. Sämtliche erreichbaren API-Schlüssel, Cloud-Zugangsdaten, Tokens, SSH-Schlüssel und sonstigen Geheimnisse müssen ersetzt werden. Auch Protokolle von Cloud-Anbietern und LLM-Diensten sind auf ungewöhnliche Zugriffe und Kosten zu prüfen.
Wie viele Installationen Version 1.107.0 tatsächlich heruntergeladen und ausgeführt haben, ist bislang nicht bekannt. Bei einer früheren LiteLLM-Kompromittierung im März waren möglicherweise mehr als 2.500 Organisationen und 434.000 CI/CD-Pipelines betroffen. Diese Zahlen lassen sich nicht auf den aktuellen Vorfall übertragen, zeigen aber die mögliche Reichweite zentraler Entwicklungsabhängigkeiten.
Gefälschtes Repository erreichte die Release-Pipeline
Der Schadcode stammt aus manipulierten Commits in einem GitHub-Repository namens Berri-AI. Der Name ähnelt der legitimen Organisation BerriAI, enthält aber einen zusätzlichen Bindestrich. Von dort gelangten die drei Dateien in die offizielle Release-Pipeline.
Wie die Angreifer die Commits aus dem gefälschten Repository technisch in den offiziellen Build-Prozess einschleusen konnten, ist noch nicht geklärt. Auch zur Identität der Täter und zu den Betreibern der verwendeten Domain liegen keine bestätigten Angaben vor.
Der Fall ähnelt anderen Angriffen auf Software-Lieferketten, etwa der Infektion des Tensorlake-SDK auf npm. Bei solchen Vorfällen reicht die Prüfung des eigenen Quellcodes nicht aus. Vertrauenswürdige Pakete können nachträglich über manipulierte Veröffentlichungsprozesse zum Einfallstor werden.
Self-Hosting braucht kontrollierte Abhängigkeiten
LiteLLM hilft Unternehmen dabei, Zugriffe auf mehrere KI-Anbieter zentral zu steuern. Das kann Kosten senken, Modellwechsel vereinfachen und die Abhängigkeit von einem einzelnen Anbieter reduzieren. Gleichzeitig bündelt ein solches Gateway besonders wertvolle Zugangsdaten an einer Stelle.
Für Unternehmen im DACH-Raum ist der Vorfall vor allem bei automatisierten Builds und Container-Deployments relevant. Wer unfixierte Tags wie latest verwendet, kann eine manipulierte Version übernehmen, ohne eine bewusste Aktualisierung freizugeben. Vergleichbare Risiken bestehen auch bei anderen zentralen KI-Schnittstellen, wie die bekannten Sicherheitslücken in internen MCP-Integrationen zeigen.
Self-Hosting beseitigt Abhängigkeiten nicht automatisch. Es verschiebt sie von einem SaaS-Anbieter auf Pakete, Container-Images und deren Release-Prozesse. Notwendig sind deshalb fest gesetzte Versionsnummern, verifizierte Artefakte, Dependency-Scanning, getrennte Berechtigungen und eine zentrale Verwaltung kurzlebiger Zugangsdaten.
Für LiteLLM gilt aktuell Version 1.106.2 als letzter bekannter sicherer Stand vor dem Vorfall. Ein Downgrade allein genügt jedoch nicht, wenn Version 1.107.0 bereits ausgeführt wurde. In diesem Fall muss von kompromittierten Geheimnissen und einer möglichen Fernsteuerung des Systems ausgegangen werden.