LiteLLM-Sicherheitslücke CVE-2026-59822 aktiv ausgenutzt

LiteLLM-Sicherheitslücke CVE-2026-59822: Erfundener Bearer-Token öffnet den MCP-Endpunkt, CISA meldet aktive Ausnutzung. Jetzt auf Version 1.84.0+ updaten.

Die LiteLLM-Sicherheitslücke CVE-2026-59822 steht seit dem 2. September 2026 im Katalog der aktiv ausgenutzten Schwachstellen (KEV) der US-Behörde CISA. Betroffen ist der MCP-Endpunkt des beliebten KI-Gateways: Ein beliebiger, frei erfundener Bearer-Token reichte aus, um ohne gültigen LiteLLM-Key auf die angebundenen MCP-Tools zuzugreifen. Der Patch ist seit Mai da (Version 1.84.0 vom 14. Mai 2026) – wer ihn noch nicht eingespielt hat, sollte das jetzt tun.

Was die Lücke ausmacht

LiteLLM ist ein Proxy, der Anfragen im OpenAI-Format an Dutzende LLM-Anbieter weiterreicht. Viele Teams nutzen es als zentrales KI-Gateway, inklusive Schlüsselverwaltung und Kostenkontrolle. Seit einiger Zeit kann LiteLLM auch MCP-Server (Model Context Protocol) anbinden – also Werkzeuge, die ein Modell aufrufen darf: Datenbanken, Ticketsysteme, interne APIs.

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

Genau dieser MCP-Streamable-HTTP-Endpunkt hatte laut Advisory einen Logikfehler. Der Auth-Handler unterstützt OAuth2-Passthrough für vorgelagerte MCP-Server. Schlug die Prüfung des LiteLLM-Keys fehl, griff ein Fallback-Pfad und setzte statt einer Ablehnung ein leeres Berechtigungsobjekt. Ergebnis: Eine Anfrage mit gefälschtem Authorization-Header erreichte die MCP-Tools, als wäre sie authentifiziert. Ein Angreifer konnte konfigurierte Tools auflisten, aufrufen und damit die dahinterliegenden Dienste nutzen.

Die Kennzahlen laut CVE-Eintrag: CVSS 4.0 mit 8,8 (hoch), Schwachstellenklasse CWE-287 (fehlerhafte Authentifizierung). Betroffen sind alle Versionen vor 1.84.0; die Version 1.84.0 behebt das Problem. Das GitHub-Advisory GHSA-7488-6r32-c95q wurde am 30. Juni 2026 veröffentlicht, der CVE-Eintrag folgte am 8. Juli 2026. Neu ist die Einstufung als aktiv ausgenutzt: The Hacker News berichtet unter Berufung auf Wiz, dass in Honeypots Angriffsversuche gegen genau diese Lücke beobachtet wurden, um Modell-Endpunkte auszuspähen.

Warum KI-Gateways gerade Ziel Nummer eins sind

CVE-2026-59822 ist bereits die zweite LiteLLM-Lücke im KEV-Katalog. Im Juni ging es um CVE-2026-42271, eine Command-Injection mit Codeausführung. Microsoft beschreibt in einem aktuellen Bericht, wie Angreifer über solche Lücken in LiteLLM-Instanzen eindringen, Krypto-Miner nachladen und dann gezielt die PostgreSQL-Tabellen des Gateways abgrasen – dort liegen Provider-Keys für OpenAI, Anthropic und Co. sowie die von LiteLLM ausgegebenen virtuellen Schlüssel. Ähnliches sahen wir zuletzt bei Langflow.

Das Muster ist klar: Ein KI-Gateway ist ein Tresor voller fremder API-Schlüssel, oft mit direktem Draht in interne Systeme. Für Angreifer ist das lukrativer als ein einzelner Webserver.

Was das für dich bedeutet

Aus der Praxis kenne ich das Problem in einer bestimmten Form: KI-Gateways werden als „Entwickler-Tool” eingeführt, nicht als Infrastruktur. Sie laufen in einem Docker-Container auf einer VM, die niemand im Patch-Zyklus hat, und hängen mit einer öffentlichen IP im Netz, weil ein Kollege im Homeoffice darauf zugreifen wollte. Der MCP-Teil verschärft das Ganze, denn hier geht es nicht mehr nur um Token-Kosten, sondern um Werkzeuge, die im Namen des Unternehmens handeln – ein Tool, das Tickets anlegt, Mails sendet oder Datenbanken abfragt.

Die Lücke selbst ist ein klassischer „Fail open”-Fehler: Im Fehlerfall wird durchgewunken statt blockiert. Solche Fehler entstehen, wenn Authentifizierung nachträglich um Sonderpfade erweitert wird. Sie sind schwer zu testen, weil das System im Normalbetrieb korrekt wirkt.

Konkrete Praxis-Tipps

Version prüfen und aktualisieren: pip show litellm bzw. das Docker-Image-Tag ansehen. Alles unter 1.84.0 ist verwundbar – auf die aktuelle Version gehen, nicht nur auf 1.84.0.
Exposition beenden: Ein LiteLLM-Proxy gehört nicht ohne vorgeschaltete Authentifizierung ins Internet. Reverse-Proxy mit mTLS, VPN oder zumindest IP-Allowlist. Prüfe, ob der Port 4000 (Standard) von außen erreichbar ist.
MCP-Tools minimal halten: Jedes angebundene Tool ist eine Angriffsfläche. Frage bei jedem: Braucht das Modell dieses Werkzeug wirklich, und mit welchen Rechten?
Kompromittierung ausschließen: Logs des MCP-Endpunkts auf Zugriffe mit unbekannten Tokens durchsehen. Im Zweifel alle Provider-Keys und virtuellen Keys rotieren – die Datenbank des Gateways ist das eigentliche Ziel.
Gateways wie Server behandeln: Inventar, Patch-Zyklus, Monitoring. Wer LLMs lieber komplett im eigenen Haus betreibt, findet in unserem Ratgeber zu Hardware für lokale KI einen Einstieg – aber auch ein lokales Setup braucht dieselbe Disziplin.

Einordnung

Für US-Bundesbehörden gilt laut CISA-Vorgabe eine Frist bis zum 16. September 2026. Diese Frist ist eine sinnvolle Orientierung für alle anderen auch. Die Lücke ist seit fast vier Monaten gepatcht, der Exploit ist trivial, und KI-Infrastruktur taucht im Katalog der aktiv ausgenutzten Schwachstellen inzwischen regelmäßig auf – LiteLLM allein zweimal binnen drei Monaten. Wer LiteLLM, Langflow, Flowise oder Ollama betreibt, sollte diese Komponenten in dieselbe Liste aufnehmen wie seine Firewalls und VPN-Gateways.

Quellen

Dranbleiben

Diese Analysen als Newsletter

Ein Mal pro Woche Klartext zu KI, Security & Crypto – direkt in dein Postfach.

Jetzt anmelden

LiteLLM-Sicherheitslücke CVE-2026-59822: MCP-Endpunkt ließ jeden Token durch – CISA warnt