LiteLLM 1.107.0: Wenn die KI-Bibliothek selbst der Angreifer ist

Kurz gesagt

Am 21. Oktober war die offizielle Version 1.107.0 der KI-Bibliothek LiteLLM rund zwei Stunden lang mit Schadcode verseucht, der Zugangsdaten stiehlt. Betroffen ist, wer an diesem Tag LiteLLM per pip oder als Docker-Image aktualisiert hat, auch über eine Agentur. Fragen Sie nach, ob 1.107.0 je bei Ihnen lief, und lassen Sie im Zweifel alle Schlüssel tauschen.

Was ist passiert?

LiteLLM ist ein Baustein, mit dem Entwickler viele KI-Modelle über eine einheitliche Schnittstelle ansprechen, etwa OpenAI, Anthropic oder Google. Viele selbst gebaute Chatbots und KI-Automatisierungen nutzen ihn, oft als zentralen „Proxy“, der alle API-Schlüssel des Betriebs verwaltet.

Angreifer hatten sich Zugang zu Konten von Entwicklern des Projekts verschafft. Damit haben sie die offizielle Veröffentlichungskette auf eine Kopie des Quellcodes umgelenkt, deren Name sich nur durch einen Bindestrich vom echten unterscheidet. Das Ergebnis trug die echte Versionsnummer, kam aus den echten Kanälen und war sogar gültig signiert. Das nennt man einen Lieferkettenangriff: Nicht Ihr System wird angegriffen, sondern ein Baustein, dem Ihr System vertraut.

Der Schadcode startet bei jedem Python-Aufruf auf dem betroffenen Rechner und sammelt Cloud-Zugänge, SSH-Schlüssel, KI-API-Schlüssel und gespeicherte Passwörter. Der Hersteller hat die Version nach rund zwei Stunden entfernt.

Was bedeutet das?

Für einen Betrieb, der sich eine KI-Anwendung bauen lässt, verschiebt sich die Frage. Es reicht nicht, dass der Code der Agentur sauber ist. Jede Bibliothek, die beim Bauen automatisch in der neuesten Fassung geholt wird, kann an einem schlechten Tag die falsche sein. Genau diese Fälle traf es: wer ohne feste Versionsnummer installiert oder das Docker-Image latest gezogen hat.

Bei einem LiteLLM-Proxy ist der Schaden besonders breit, weil dort die Schlüssel zu allen KI-Anbietern liegen. Ein gestohlener Schlüssel heißt im einfachsten Fall fremde Rechnungen auf Ihrem Konto, im schlimmeren Fall Zugriff auf Daten, die über diese Schnittstellen laufen.

Es ist der zweite Vorfall dieser Art bei LiteLLM in diesem Jahr. Das spricht nicht gegen das Werkzeug, aber für feste Regeln im Umgang damit.

Was Sie jetzt tun können

1. Nachfragen, ob LiteLLM im Einsatz ist. An Agentur oder Entwickler: „Nutzt eine unserer KI-Anwendungen LiteLLM, als Bibliothek oder als Proxy-Container?“
2. Prüfen lassen, ob 1.107.0 je lief. Vorlage: „Bitte prüfen Sie, ob litellm 1.107.0 oder ein Docker-Image mit den Tags latest, main-latest oder main-stable vom 21. Oktober 2026 in einer unserer Umgebungen installiert oder gestartet wurde, auch in Test- und Build-Umgebungen.“ Hinweis an den Techniker: Der Hersteller nennt pip show litellm und die Suche nach litellm-1.107.0.dist-info, cook.pth und sitecustomize.py. Ein Fund belegt den Befall, kein Fund beweist nicht das Gegenteil.
3. Falls ja: als kompromittiert behandeln. Umgebung neu aufbauen statt reparieren, auf 1.106.2 oder eine geprüfte spätere Version festlegen, dann von einem sauberen Rechner aus alle Schlüssel tauschen, die dort erreichbar waren: KI-Anbieter, Cloud, Datenbank, Git.
4. Feste Versionen vereinbaren. Lassen Sie sich zusichern, dass Ihre KI-Anwendungen Bibliotheken mit fester Versionsnummer einbinden und Container nicht über latest beziehen. Updates sollten bewusst und mit etwas Abstand zur Veröffentlichung erfolgen.
5. Schlüssel klein halten. Jede Anwendung bekommt eigene API-Schlüssel mit Ausgabenlimit beim KI-Anbieter. Dann bleibt ein Diebstahl begrenzt.

Häufige Fragen

Wir nutzen nur ChatGPT im Browser. Betrifft uns das? Nein. Es betrifft selbst gebaute oder selbst betriebene Anwendungen, in denen LiteLLM steckt. Die Version ist doch längst entfernt. Warum noch handeln? Weil der Schadcode beim Entfernen des Pakets bleibt und gestohlene Schlüssel gültig sind, bis sie getauscht werden. Woran erkenne ich eine gute Agentur in dieser Frage? Sie kann Ihnen ohne Nachschlagen sagen, welche Versionen in Ihrer Anwendung stecken und wie Updates freigegeben werden.

Quellen

• LiteLLM: Contained, Oct 21, 2026 LiteLLM release v1.107.0 Compromised (21. Oktober 2026, mit Updates bis 30. Oktober 2026)
• Datadog Security Labs: LiteLLM supply chain compromise, What you need to know (21. Oktober 2026)
• OSV: MAL-2026-2144, Malicious code in litellm (PyPI) (aktualisiert 29. Oktober 2026)

Stand: 31. Oktober 2026. Ersetzt keine Prüfung im Einzelfall. Transparenz: Diese Einordnung ist KI-generiert mit menschlicher Prüfung, gekennzeichnet nach Art. 50 der europäischen KI-Verordnung. Auswahl, Quellenprüfung und Freigabe: Schoonnect.