🔥 Das LiteLLM-Paket wurde gehackt. Wenn Sie mit LLM-APIs arbeiten, ist es Zeit, sich zu sorgen.

Gestern gab es im Python-Ökosystem einen mustergültigen Supply-Chain-Angriff. Das Paket litellm wurde kompromittiert – eine Bibliothek mit 97 Millionen Downloads pro Monat, die heute in vielen KI-Projekten steckt.

In PyPI wurde die infizierte Version 1.82.8 veröffentlicht. Darin wurde sorgfältig eine Datei litellm_init.pth mit einer Base64-Ladung platziert, die eine einfache Sache tat: Sie saugte Ihren Rechner nach allen Geheimnissen ab und sendete sie an einen entfernten Server, während sie sich selbst replizierte.

Die Liste der „gestohlenen“ Daten umfasste alles, was das Skript erreichen konnte:
▫️ SSH-Schlüssel
▫️ Anmeldedaten von AWS/GCP/Azure
▫️ Kubernetes-Konfigurationen
▫️ .env-Dateien (Hallo, Ihre OpenAI-Tokens)
▫️ Terminalverlauf und Datenbank-Passwörter
▫️ Private SSL-Schlüssel und Krypto-Wallets

Dabei mussten Sie nicht einmal pip install litellm ausführen, um Ihre Produktionsschlüssel preiszugeben. Es reichte, ein beliebiges Tool zu installieren oder zu aktualisieren, das es als transitive Abhängigkeit mitzieht. Zum Beispiel: Sie aktualisieren das beliebte dspy (das in seinen requirements litellm>=1.64.0 hat) – willkommen im Club der Gehackten.

Doch in dieser ganzen Geschichte gibt es einen erstaunlichen Aspekt.

Die Branche wurde vor einer globalen Katastrophe dadurch bewahrt, dass der Hacker ein schlechter Programmierer war. 🤡
Die Malware war so schlecht geschrieben, dass sie Speicherlecks verursachte. Ein Typ nutzte ein Plugin in Cursor, das im Hintergrund das aktuelle litellm zog. Das Skript fraß den gesamten Arbeitsspeicher und stürzte das System ab. Dadurch blieb die infizierte Version weniger als eine Stunde in PyPI, bevor sie entfernt wurde.

Hätte der Angreifer seinen Code ordentlich getestet, hätte der Exploit wochenlang aktiv sein können. Die Hälfte der KI-Startups wäre morgen pleite wegen durchgesickerter Kundendaten und geplünderter Cloud-Budgets.

Andrej Karpathy äußerte dazu eine Meinung: Das klassische Entwicklungsparadigma „wir bauen Pyramiden aus Abhängigkeitsbausteinen“ wird in der heutigen Realität zu einer fatalen Schwachstelle. Jahrzehntelang wurde uns das akademische Muster gelehrt: „Erfinde das Rad nicht neu, verwende es wieder, nimm eine fertige Bibliothek.“
In der heutigen Lieferketten-Realität ist das wie russisches Roulette. Jedes Mal, wenn Sie eine neue Abhängigkeit in Ihr Projekt ziehen, ziehen Sie deren gesamten Baum bis in die zehnte Ebene mit. Und irgendwo dort könnte ein verärgerter Maintainer oder ein gehacktes Konto sitzen.

Das Paradigma ändert sich. Anstatt eine riesige Bibliothek für ein paar Hilfsfunktionen zu ziehen, ist es heute sicherer und pragmatischer, einfach das benötigte Code-Stück zu kopieren (oder per LLM zu generieren) und in Ihrem Repository zu sperren. 🤷‍♂️