Sogar Karpathy hat Angst bekommen. Ein KI-Paket mit 90 Millionen Downloads wurde vergiftet, und es war tatsächlich ein Hacker, der durch das Schreiben eines Bugs das Rettungswort sagte.
Gerade jetzt hat die Technologiebranche eine aufregende Krise des "Supply - Chain - Poisonings" durchlebt.
Am Vormittag des 24. März erschien ein gewöhnlicher Version - Update, LiteLLM 1.82.8, auf PyPI.
Täglich holen die Endgeräte von Millionen von Entwicklern weltweit automatisch solche Updates ab. Niemand bemerkte, dass in dieser Version ein sorgfältig entworfener Schadcode versteckt war:
Sobald Sie den Befehl "pip install litellm" ausführen, werden die SSH - Schlüssel, Cloud - Dienst - Anmeldeinformationen, Datenbankpasswörter, Kryptowallets usw. auf Ihrem Computer innerhalb weniger Sekunden verschlüsselt, gepackt und an einen Server gesendet, der sich als offiziell ausgibt.
Dann, wenn Ihr Computer mit einem Kubernetes - Cluster verbunden ist, wird der Schadcode automatisch horizontal verbreitet und hinterlässt auf jedem Knoten eine Hintertür.
LiteLLM ist eine der zentralen Infrastrukturen bei der Entwicklung von AI - Anwendungen. Die monatliche Downloadmenge seines Open - Source - Pakets weltweit beträgt 97 Millionen.
Dieses Mal war diese Pipeline jedoch fast von innen durchbrochen worden, und dass es glücklicherweise nicht dazu kam, war rein zufällig.
Der Angreifer hatte einen Fehler in seinem eigenen Code, der dazu führte, dass das Zielgerät direkt abstürzte. Wenn es diesen Fehler nicht gegeben hätte, wüsste niemand, wie lange sich dieses "Vergiftung" noch verbreitet hätte.
Als Andrej Karpathy dies sah, schrieb er in der Nacht einen Beitrag und nannte es "Software - Schreckgespenst".
Die "Diebstahlsliste", die Karpathy in seinem Beitrag aufführte, war wie eine "Katastrophenszene":
AWS/GCP/Azure - Anmeldeinformationen, Kubernetes - Konfiguration, CI/CD - Geheimnisse, Datenbankpasswörter, SSH - Schlüssel...
Nach diesem "Schreckgespenst" sagte Karpathy ein Wort, das das gesamte Branchen - Entwicklungsparadigma verändern könnte:
"Ich bin immer widerspenstiger gegenüber Abhängigkeiten."
pip install, und dann ist alles weg
Dies ist keine gewöhnliche Sicherheitslücken - Warnung. Sobald Sie diesen scheinbar harmlosen Befehl "pip install litellm" in der Konsole eingeben, wird Ihr gesamter Computer dem Angreifer sofort vollständig zugänglich.
Nach Sicherheitsanalysen ging es bei diesem Vergiftungseingriff nicht einfach darum, ein paar Passwörter zu stehlen, sondern um eine "umfassende Plünderung" des gesamten Computers und des gesamten Clusters.
Die Diebstahlsliste des Angreifers deckte fast alles ab, was für Entwickler am wichtigsten ist:
- SSH - Private Schlüssel und Konfiguration
- AWS/GCP/Azure - Anmeldeinformationen
- Kubernetes - Konfiguration und Token
- API - Key in.env
- Git - Anmeldeinformationen
- Datenbankpasswörter
- Shell - Verlauf
- SSL - Private Schlüssel
- CI/CD - Geheimnisse
- Kryptowallet - Dateien
- Empfindliche Informationen in Umgebungsvariablen
Was noch erschreckender ist, ist, dass LiteLLM überhaupt kein unbekanntes Tool ist.
Als wichtiges Middleware, das verschiedene Sprachmodell - Anbieter verbindet, ist es der echte "Wasser-, Strom- und Gasversorger" der AI - Anwendungsebene und hat eine monatliche Downloadmenge von bis zu 97 Millionen!
Viele Projekte nutzen es, um sich einheitlich mit Anbietern wie OpenAI, Anthropic, Google, Azure usw. zu verbinden.
Viele Agent - Frameworks, MCP - Server und LLM - Orchestrierungstools nutzen es auch als unterliegende Abhängigkeit.
Dadurch hat sich die Auswirkung dieses Vergiftungseingriffs auf ein Riss in der gesamten AI - Abhängigkeitskette ausgeweitet.
Selbst wenn Sie überhaupt nicht wissen, was LiteLLM ist, werden Sie als Opfer der indirekten Abhängigkeit in die Falle geraten, wenn Sie "pip install dspy" ausführen (das von "litellm>=1.64.0" abhängt) oder ein anderes großes AI - Projekt installieren, das von diesem Paket abhängt.
Einmal vergiftet, breitet sich der Schadcode entlang des komplizierten Abhängigkeitsbaums sofort auf unzählige AI - Projekte aus.
Deshalb hat Karpathy es direkt als "Schreckgespenst der Softwarewelt" definiert.
Eine epische Sicherheitslücke, die erst durch die "schlechte Codierung" des Hackers aufgedeckt wurde
Sie mögen denken, dass Sicherheitsunternehmen sofort Alarm schlugen, da die Auswirkungen so groß waren?
Aber die Wahrheit ist etwas absurd und ironisch.
Die ersten, die die Anomalie bemerkten, waren die Ingenieure des Callum McMahon - Teams.
Damals verwendeten sie in Cursor ein MCP - Plugin, das LiteLLM als indirekte Abhängigkeit einführte.
Nach der Installation der vergifteten Version LiteLLM 1.82.8 begann der Computer plötzlich unnormal zu funktionieren: Der Arbeitsspeicher wurde rasch vollgepackt, und schließlich stürzte der Computer ab.
Später stellte man fest, dass das Problem in einer.pth - Datei lag.
Für viele Python - Entwickler hat die.pth - Datei normalerweise fast keine Bedeutung.
Aber genau deshalb kann sie beim Start des Python - Interpreters automatisch Code ausführen. Der Angreifer hat hier einen Schadcode - Starter eingefügt.
Nach dem ursprünglichen Plan sollte es heimlich einen Subprozess starten und die nachfolgende Logik zum Stehlen von Informationen und zum Senden an außen ausführen.
Es ist aber fehlgeschlagen.
Da der Subprozess selbst die gleiche.pth - Datei erneut auslöst, erzeugt jeder neue Prozess wiederum neue Prozesse, was zu einer exponentiellen Selbstreplikation führt und schließlich zu einer "fork bomb", die die Computerressourcen schnell verbraucht.
D.h., dass dieser Angriff nur deshalb aufgedeckt wurde, weil er sich selbst zerstört hat.
Wenn der Angreifer nicht durch ungenaue Codierung diesen Fehler gemacht hätte, hätte diese so versteckte Hintertür sehr wahrscheinlich mehrere Wochen oder sogar Monate lang im Netz unentdeckt bleiben können.
Die Sicherheitsbarriere der gesamten Branche beruhte auf einem Fehler des Hackers. Das Sicherheitsüberprüfungssystem der gesamten Ökosystem war in diesem Moment wirkungslos.
Das ist auch das beängstigendste an dieser ganzen Geschichte.
Eine sorgfältig geplante "Supply - Chain - Vergiftung"
Aus der Präzision der Angriffsmethode lässt sich ersehen, dass dies eine organisierte "Supply - Chain - Vergiftung" war.
Zunächst hat der Angreifer auf unbekannte Weise das PyPI - Konto des Betreuers gehackt und direkt den offiziellen CI/CD - Veröffentlichungsprozess umgangen, indem er die Versionen v1.82.7 und v1.82.8 mit Hintertüren in das PyPI - Repository hochgeladen hat.
Im GitHub - Quellcode - Repository von LiteLLM finden Sie sogar keine entsprechenden Tags oder Release - Einträge.
Zweitens besteht die Angriffs - Payload aus drei äußerst professionellen Phasen:
In der ersten Phase erfolgt eine präzise "Sammelaktion" im großen Stil;
In der zweiten Phase wird mit dem eingebauten 4096 - Bit - RSA - öffentlichen Schlüssel in Kombination mit AES - 256 - CBC eine starke "Verschlüsselung" durchgeführt, und die Daten werden an eine sehr täuschende Falsch - Domain (models.litellm.cloud) gesendet;
Die dritte Phase ist am gefährlichsten. Wenn Kubernetes - Anmeldeinformationen in der Umgebung vorhanden sind, wird es direkt "horizontal wandern", alle Secrets in allen Namespaces des Clusters lesen und auf allen Knoten privilegierte Pods erstellen und dauerhafte Hintertüren einbauen.
Die Schadcode - Datei litellm_init.pth von LiteLLM 1.82.8 wird automatisch beim Start des Python - Interpreters ausgelöst und führt dann den dreistufigen Payload - Angriff aus.
Ein besonders gruseliges Detail ereignete sich nach dem Vorfall:
Als die Community versuchte, das Ereignis in einem GitHub - Issue zu diskutieren, schloss der Besitzer das Issue direkt mit "not planned" und wurde anschließend von Hunderten von Bot - Accounts überschwemmt.
Das Konto des Betreuers und die Entwicklungsumgebung wurden offensichtlich vollständig übernommen, und der Angreifer versucht systematisch, die Spuren zu verdecken.
Derzeit hat das LiteLLM - Team eingegriffen und vermutet, dass dieses Ereignis mit einem größeren Trivy - Sicherheitsereignis in Verbindung steht (vermutlich wurden gestohlene Anmeldeinformationen verwendet) und hat dringend das Google Mandiant - Sicherheitsteam kontaktiert, um Beweise zu sammeln.
Glücklicherweise sind die Benutzer der offiziellen Docker - Images, die die Version festgelegt hatten, unversehrt geblieben.
Aber diese vollständige APT - Methode (Advanced Persistent Threat) hat die "Kriegsintensität" erhöht.
Karpathys "Anti - Abhängigkeits - Manifest", das AI - Entwicklungsparadigma ändert sich
Diese Katastrophe verändert tiefgreifend die Grundannahmen von Silicon Valley - Technologieeliten über Softwareentwicklung.
Die traditionelle Softwareentwicklungstheorie lehrt uns immer: Man soll nicht ständig neue "Räder" erfinden. Abhängigkeiten sind die festen Bausteine für das Aufbauen eines großen Pyramidenschachtes.
Aber nach diesem Ereignis hat Karpathy in einem Tweet sein "Anti - Abhängigkeits - Manifest" veröffentlicht:
Deshalb bin ich immer widerspenstiger gegenüber Abhängigkeiten und neige dazu, wenn die Funktionen einfach genug sind und tatsächlich machbar sind, direkt mit einem LLM eine Funktion zu "holen" und zu verwenden.
Von "Abhängigkeiten sind Bausteine" zu "Abhängigkeiten sind Zeitbomben", dies ist nicht nur die Entladung von Emotionen, sondern auch ein großer Wendepunkt im AI - Entwicklungsparadigma.
Jedes Mal, wenn Sie "pip install" ausführen, bringen Sie an einem tief verborgenen Punkt des gesamten Abhängigkeitsbaums eine tödliche unbekannte Gefahr ein.
Wenn die großen Modelle stark genug sind, um die unterliegende Logik von Drittanbieter - Abhängigkeiten direkt zu generieren und zu ersetzen, wird "weniger Abhängigkeit" nicht länger eine Code - Reinheitsfetisch sein, sondern eine zentrale Sicherheitsstrategie.
Darin verbirgt sich auch eine ironische Schleife:
Callum ist in die Falle geraten, weil er das AI - Codierungstool Cursor verwendet hat und über das MCP - Plugin das AI - Middleware litellm eingeführt hat.
Die AI - Toolkette selbst ist die größte Angriffsfläche.
AI schafft rasch neue Paradigmen zur Problemlösung, aber gleichzeitig auch bisher unbekannte Sicherheitslücken.
Die "Vertrauenskrise" hinter 97 Millionen Downloads
Das LiteLLM - Team hat bereits Maßnahmen ergriffen, um die Schäden einzudämmen:
Die kontaminierten Versionen wurden entfernt; die Anmeldeinformationen der Betreuer wurden geändert; neue autorisierte Betreuer wurden ernannt; Mandiant wurde kontaktiert, um eine Beweisaufnahme durchzuführen; die Benutzer wurden aufgefordert, die betroffenen Versionen zu prüfen, Indikatoren des Kompromisses (IoC) zu suchen und alle Anmeldeinformationen zu ändern.
https://docs.litellm.ai/blog/security-update-march-2026
Obwohl das LiteLLM - Ereignis in weniger als einer Stunde wie ein "Farce" endete, die kontaminierten Versionen zurückgenommen und die Anmeldeinformationen geändert wurden, ist das wirklich Beunruhigende, dass dieses Ereignis nicht zu einer größeren stillen Katastrophe wurde, nicht weil das Sicherheitsystem es entdeckte, sondern weil der Hacker einen Fehler gemacht hat.
Die monatliche Downloadmenge von 97 Millionen bedeutet, dass die gesamte Branche 97 Millionen Mal "Vertrauenswetten" gemacht hat.
Dieses "Vergiftungsevent" hat gezeigt, dass das Vertrauensmodell der Open - Source - Supply - Chain in der AI - Infrastruktur möglicherweise äußerst fragil ist:
Sie denken, dass Sie auf Tausende von Zeilen überprüften Open - Source - Codes vertrauen, aber tatsächlich vertrauen Sie nur darauf, dass ein weit entfernt gelegener Paketbetreuer nicht sein PyPI - Konto - Passwort verloren hat oder sein Computer nicht mit Malware infiziert ist.
Dieses systemische Sicherheitsrisiko ist zweifellos ein schwerer Schlag für die AI - Ökosystem, das stark auf Open - Source - Pakete angewiesen ist.