„Sehr wahrscheinlich vollständig kompromittiert“, sagt der Sicherheitsforscher über den Autor der populären LiteLLM-Bibliothek. Stellen Sie sich vor, das harmlose Python-Paket, das Sie gestern geupdated haben, schreibt heimlich Ihre SSH-Schlüssel auf den Server eines Angreifers.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Das Wichtigste in Kürze
- Die KI-Proxy-Bibliothek LiteLLM wurde über PyPI mit Schadsoftware infiziert
- Betroffen sind die Versionen 1.82.7 und 1.82.8 vom 24. März 2026
- Die Schadsoftware stiehlt SSH-Schlüssel, Cloud-Credentials und Datenbank-Passwörter
- Sie verbreitet sich aktiv in Kubernetes-Clustern und richtet Hintertüren ein
Was ist passiert?
Der Vorfall wurde von Sicherheitsforscher Callum McMahon von Futuresearch entdeckt. Am 24. März 2026 wurden die Versionen 1.82.7 und 1.82.8 der Open-Source-Bibliothek LiteLLM kompromittiert, ohne dass es eine entsprechende Freigabe im offiziellen GitHub-Repository gegeben hätte. LiteLLM ist ein populärer Proxy für KI-Sprachmodell-APIs und wird in tausenden KI-Stacks weltweit eingesetzt.
Die Schadsoftware stiehlt SSH-Schlüssel, Cloud-Zugangsdaten, Datenbank-Passwörter und Kubernetes-Konfigurationen. Sie verschlüsselt diese Informationen und schickt sie an einen fremden Server. Zusätzlich verbreitet sie sich in Kubernetes-Clustern und richtet dort dauerhafte Hintertüren ein. Entdeckt wurde der Angriff zufällig, als das Paket innerhalb des Code-Editors Cursor abstürzte.
Wer ist betroffen?
Die Reichweite ist beträchtlich. Wer die kompromittierten Versionen seit dem 24. März 2026 installiert oder als Abhängigkeit im Build-Prozess gezogen hat, sollte vom Vollkompromiss ausgehen. Das gilt insbesondere für CI/CD-Pipelines, in denen LiteLLM ohne Pinning auf eine bestimmte Version läuft.
Der Schaden kaskadiert. Wenn ein Angreifer SSH-Schlüssel hat, kommt er in andere Systeme. Wenn er Cloud-Credentials hat, kann er in Cloud-Konten wechseln. Wer LiteLLM in einem Kubernetes-Cluster betreibt, hat es mit lateraler Verbreitung zu tun, also nicht nur mit einer Kompromittierung des einen Pods.
KI-Stacks sind die neuen Supply-Chains. Wer 2026 Python-Pakete ohne Versions-Pinning und ohne Hash-Verifikation einsetzt, baut sich seine eigene Backdoor. Cursor hat den Angriff zufällig durch einen Absturz aufgedeckt, das nächste Mal wird es lautlos sein.
— Michael Dobler, Herausgeber Dr. Web
Was sollten Administratoren sofort tun?
Vier Sofortmaßnahmen.
Erstens: Alle Zugangsdaten wechseln, die auf Systemen mit den betroffenen LiteLLM-Versionen lagen. Das umfasst SSH-Schlüssel, Cloud-Credentials, Datenbank-Passwörter und Kubernetes-Service-Accounts.
Zweitens: Kubernetes-Cluster auf laterale Verbreitung der Schadsoftware prüfen und alle Pods neu ausrollen.
Drittens: Build-Pipelines auf Versions-Pinning umstellen, idealerweise mit Hash-Verifikation.
Viertens: NVIDIAs AI-Director Jim Fan empfiehlt, Abhängigkeiten zu minimieren und stattdessen schlanke Eigenlösungen zu bauen.
Der Vorfall reiht sich ein in eine Serie aktueller Supply-Chain-Angriffe. Die Geschwindigkeit, mit der KI-Agenten Schwachstellen finden, hat das Tempo der Angriffe drastisch erhöht. Manuelle Audits reichen nicht mehr aus.
Welche strukturellen Lehren sind zu ziehen?
Drei Punkte.
Erstens: KI-Stack-Sicherheit ist kein Spezialthema, sondern Teil der allgemeinen Supply-Chain-Sicherheit.
Zweitens: Code-Editoren wie Cursor sind nicht nur Produktivitätswerkzeuge, sondern auch Angriffsvektoren. Wer einen kompromittierten Agenten betreibt, kann auf allen verbundenen Konten täuschend echt imitiert werden.
Drittens: Die Branche braucht Zertifizierungs- und Signierungsstandards für KI-relevante Pakete, ähnlich wie sie sich im Linux-Distributions-Ökosystem etabliert haben.
Was sollten IT-Leiter in der Folge prüfen?
Drei Empfehlungen.
Erstens: SBOM-Inventur. Welche KI-Pakete laufen in Ihrer Infrastruktur, in welcher Version, mit welcher Hash-Prüfung?
Zweitens: Notfall-Übung. Wenn morgen ein populäres KI-Paket kompromittiert wird, wie schnell können Sie alle betroffenen Systeme identifizieren und Credentials rotieren?
Drittens: Strategische Frage. Lohnt sich die Abhängigkeit von vielen kleinen Drittanbieter-Paketen, oder sollten kritische Funktionen intern entwickelt werden?
Mehr Newshunger?
- Findet Claude Mythos jede Sicherheitslücke? Fast
- Neun Jahre alter Linux-Kernel-Bug wird aktiv ausgenutzt
- Anthropic Claude Memory: Was die neue Funktion bringt
- Wird KI 2026 kleiner statt größer? Kommt drauf an
Quellen
The Decoder – LiteLLM-Bibliothek mit Schadsoftware infiziert über PyPI – https://the-decoder.de/kuenstliche-intelligenz-news/ – besucht am 08.05.2026
Futuresearch – Compromise of LiteLLM versions 1.82.7 and 1.82.8 – https://futuresearch.ai/ – besucht am 08.05.2026
