Angriff auf LiteLLM: Was der Vorfall für eigene KI-Anwendungen bedeutet

Was ist passiert?

LiteLLM ist ein weit verbreiteter Baustein für eigene KI-Anwendungen: Er bündelt den Zugang zu Sprachmodellen verschiedener Anbieter. Am 21. Oktober 2026 veröffentlichten Angreifer über die echte Release-Pipeline des Projekts die Version 1.107.0 mit Schadcode. Auf PyPI war sie von 13:39 bis 15:23 Uhr deutscher Zeit verfügbar, als Docker-Image unter den Tags latest, main-latest, main-stable und v1.107.0 bis 16:20 Uhr.

Der Schadcode legte drei Dateien neben das Paket. Sie liefen bei jedem Start von Python, auch beim Aufruf von pip, nicht erst bei der Nutzung von LiteLLM. Gesammelt wurden unter anderem Cloud-Zugänge, SSH-Schlüssel, .env-Dateien, CI-Secrets und Browser-Passwörter. Auf Proxy-Servern las der Code zusätzlich die gespeicherten API-Schlüssel der KI-Anbieter aus der Datenbank.

Ursache war laut LiteLLM ein Schlüssel, der im Mai 2026 versehentlich in einem öffentlichen Repository landete und nie widerrufen wurde. Damit verschaffte sich der Angreifer GitHub-Tokens von Maintainern, schaltete Schutzmechanismen ab und gab die Version frei. Laut dem Sicherheitsunternehmen Wiz wurde Version 1.107.0 rund 49.000 Mal heruntergeladen.

Was bedeutet das?

Der Fall zeigt die neue Angriffsfläche eigener KI-Anwendungen. Ein KI-Gateway hält die Schlüssel zu allen angebundenen Modellen und oft auch zu Cloud-Konten. Wer es kompromittiert, bekommt mit einem Schlag viele Zugänge. Laut Wiz testete der Angreifer gestohlene Cloud-Zugänge wenige Stunden später, um damit KI-Modelle in AWS abzufragen.

Auffällig ist, was nicht geholfen hat: Nach einem ersten Vorfall im März hatte LiteLLM ein privates Release-Repository, vertrauenswürdige Veröffentlichung auf PyPI und signierte Images eingeführt. Ein einziger nie widerrufener Schlüssel reichte trotzdem. Sicherheit hängt hier weniger an Werkzeugen als an der Disziplin im Umgang mit Schlüsseln.

Für Unternehmen heißt das: Die Lieferkette einer KI-Anwendung gehört ins eigene Risikomanagement, genauso wie die Wahl des Modells. Eine Make-or-Buy-Entscheidung legt auch fest, wer für diese Kette verantwortlich ist.

Was Sie jetzt tun können

1. Betroffenheit prüfen, ohne Python zu starten: Suchen Sie im Dateisystem nach litellm-1.107.0.dist-info, cook.pth und sitecustomize.py sowie in Lock-Dateien, Paket-Caches und Images nach Version 1.107.0. Microsoft rät, in einer verdächtigen Umgebung weder Python noch pip auszuführen.
2. Zeitfenster abgleichen: Betroffen ist, wer am 21. Oktober zwischen 13:39 und 15:23 Uhr LiteLLM ohne feste Version installiert hat oder zwischen 13:46 und 16:20 Uhr eines der genannten Docker-Tags bezogen hat, auch automatisch über CI-Pipelines.
3. Bei einem Treffer: Schlüssel tauschen und neu bauen: Gehen Sie von einem Datenabfluss aus. Tauschen Sie von einem sauberen Rechner aus Cloud-Zugänge, API-Schlüssel der KI-Anbieter, Datenbank-Passwörter, CI-Secrets, SSH-Schlüssel und Tokens, und beenden Sie aktive Sitzungen. Bauen Sie Umgebung und Images neu, mit fest gewählter Version.
4. Künftig vorbeugen: Legen Sie Versionen mit Prüfsummen fest, beziehen Sie Container über ihren Digest statt über einen Tag, prüfen Sie Pakete vor der Aufnahme in interne Spiegel und beschränken Sie den ausgehenden Datenverkehr Ihrer KI-Server auf das Nötige.

Häufige Fragen

Quellen

• Microsoft Security Blog: Inside the LiteLLM 1.107.0 supply chain compromise: Credential theft through Python startup hooks (23. Oktober 2026)
• LiteLLM: Security incident October 21, 2026: attack chain (23. Oktober 2026)
• LiteLLM: Security incident October 21, 2026 (21. Oktober 2026)
• Wiz: LiteLLM compromised, steals credentials (21. Oktober 2026)

Stand: 25. Oktober 2026. Diese Einordnung ersetzt keine Rechtsberatung und keine Prüfung im Einzelfall.