„Vollständig kompromittiert“: Wie der LiteLLM-Angriff Ihren KI-Stack trifft

„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.

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.

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