LiteLLM-Lücke im MCP-Endpunkt landet im CISA-KEV: Was das für Teams mit KI-Gateways bedeutet

Daniel Reyes Principal Engineer (AI/ML), YuSMP Group · Baut und sichert LLM- und Agenten-Infrastruktur für Teams in den USA und der EU

Das Wichtigste in Kürze

Was CVE-2026-59822 genau bewirkt

LiteLLM von BerriAI gehört zu den am weitesten verbreiteten Open-Source-KI-Gateways: ein Proxy, der Teams eine einheitliche, OpenAI-kompatible API vor Dutzenden Modellanbietern bietet – mit Schlüsselverwaltung, Budgets, Routing und Logging an einer Stelle. Neuere Versionen sprechen zudem das Model Context Protocol (MCP), den sich etablierenden Standard, über den ein LLM externe Tools und Datenquellen aufruft. CVE-2026-59822 sitzt genau an dieser Schnittstelle – dem MCP-Streamable-HTTP-Endpunkt – und ist mit CVSS 8,8 (hoch) bewertet.

Der Mechanismus ist ein Lehrbuchfall für einen fehlerhaften Authentifizierungs-Fallback. In LiteLLM-Versionen vor 1.84.0 scheiterte eine Anfrage an den MCP-Endpunkt mit gefälschtem Authorization-Header zwar an der regulären Schlüsselprüfung, wurde aber nicht abgewiesen, sondern fiel in einen OAuth2-Passthrough-Pfad. Dieser ersetzte die gescheiterte Prüfung durch ein leeres, authentifiziertes Benutzerobjekt – die Anfrage galt als gültig und lief weiter. Ergebnis: Ein nicht authentifizierter Aufrufer konnte mit einem beliebigen Bearer-Token eine authentifizierte MCP-Sitzung aufbauen, die vom Gateway bereitgestellten Tools auflisten, aufrufen und alle nachgelagerten Dienste erreichen, an die diese Tools angebunden sind.

Die CISA nimmt Lücken nicht aus theoretischen Gründen in den KEV-Katalog auf – Voraussetzung sind Belege für aktive Ausnutzung. CVE-2026-59822 war eine von sieben Schwachstellen, die Anfang September 2026 hinzukamen, mit Behebungsfrist 16. September für zivile US-Bundesbehörden. Bemerkenswert ist die Zusammensetzung: Drei der sieben Einträge betrafen KI-Infrastruktur statt der üblichen VPNs, Mailserver und Web-Apps. KI-Infrastruktur ist damit zu einer gewöhnlichen Kategorie ausgenutzter Systeme geworden – und eine harte Patch-Frist für das LLM-Gateway eines Unternehmens ist die praktische Folge.

Warum das KI-Gateway das Ziel ist

Man könnte das als „noch eine CVE“ abhaken, doch der Ort zählt mehr als der Mechanismus. Ein KI-Gateway ist kein Randdienst, sondern ein Nadelöhr, in dem Macht gebündelt ist. Es speichert die API-Schlüssel aller dahinterliegenden Modellanbieter, hält Budgets und Routing-Regeln für die ganze Organisation und vermittelt – sobald MCP aktiv ist – den Zugriff auf die Tools und Datenquellen, die die Modelle nutzen dürfen. Wer das Gateway kompromittiert, hat nicht eine App geknackt, sondern die Zugangsdaten und die Tool-Oberfläche von allem, was darüber läuft.

MCP verschärft das. Das Protokoll existiert, damit ein LLM Tools auflisten und aufrufen kann – ein Datenbankabfrage-Tool, einen internen API-Client, einen Dateileser –, und jedes dieser Tools ist eine Tür in ein echtes System. Eine Authentifizierungsumgehung am MCP-Endpunkt heißt also nicht „ein Angreifer kann mit Ihrem Modell chatten“, sondern „ein Angreifer kann die Tools aufrufen, die Ihr Modell aufrufen darf“ – mit allen Rechten, die diese Tools haben. Für Teams, die KI-Agenten entwickeln, ist das der Kern: In der Tool-Schicht liegt die reale Handlungsfähigkeit eines Agenten – und sein Schadensradius. Eine Lücke, die diese Schicht einem anonymen Aufrufer übergibt, gleicht eher einem gestohlenen Service-Account als einem geleakten Prompt.

Was das für Teams in den USA und der EU bedeutet

Erstens: Klären Sie, ob Sie LiteLLM überhaupt einsetzen und in welcher Version. Weil sich ein LLM-Gateway so leicht aufsetzen lässt, hat es oft keinen formalen Verantwortlichen – ein Proof of Concept des Data-Science-Teams, ein Container in einem Plattform-Namespace, eine Abhängigkeit in einem größeren KI-Produkt. Jede Installation vor 1.84.0 mit erreichbarem MCP-Endpunkt ist betroffen. Aktualisieren Sie auf 1.84.0 oder neuer und belegen Sie es wie jeden KEV-Eintrag: mit einem Inventar, nicht mit Hoffnung. Die US-Frist 16. September taugt auch ohne Compliance-Pflicht als internes Ziel.

Zweitens: Behandeln Sie das KI-Gateway nicht als Komfortfunktion, sondern als Infrastruktur. MCP- und Admin-Endpunkte dürfen aus nicht vertrauenswürdigen Netzen nicht erreichbar sein und gehören hinter echte Authentifizierung und Netzwerkkontrollen, statt sich auf die Schlüsselprüfung des Gateways als einzige Hürde zu verlassen – diese Lücke zeigt, dass eine einzelne In-App-Prüfung offen ausfallen kann. Beschränken Sie jede MCP-Tool-Anbindung nach Least Privilege und rotieren Sie die im Gateway hinterlegten Provider-Schlüssel, wenn Sie eine Offenlegung nicht ausschließen können. In regulierten Umfeldern – etwa einem FinTech- oder HealthTech-Produkt, dessen Gateway-Tools Kundendaten berühren – wird ein unauthentifizierter Pfad zu diesen Tools schnell zum meldepflichtigen Vorfall.

Drittens: Nehmen Sie KI-Infrastruktur in denselben Patch-Rhythmus auf wie den Rest Ihres Stacks. Wenn drei von sieben KEV-Einträgen KI-Komponenten sind, werden Gateways, Orchestrierungsserver und Agenten-Frameworks offensichtlich wie jeder andere exponierte Dienst angegriffen. LiteLLM und vergleichbare Komponenten höchstens ein bis zwei Releases hinter dem aktuellen Stand zu halten und ihre Versionen ins Schwachstellenmanagement einzubinden, macht die nächste CVE in der KI-Infrastruktur zum Routine-Update statt zur Feuerwehrübung.

Was bedeutet das für den DACH-Markt?

Im DACH-Raum laufen LLM-Gateways wie LiteLLM häufig gerade deshalb, weil Unternehmen mehrere Anbieter parallel betreiben und für Datenschutz und Datenresidenz Modelle in EU-Rechenzentren oder selbst gehostet einbinden – das Gateway wird so zur zentralen Schaltstelle zwischen Fachanwendungen, Modellen und internen Systemen. Wer es in der Plattformlandschaft nicht als eigenes Asset führt, übersieht es im Patch-Management leicht.

Rechtlich ist der Rahmen klar: Gelangt ein Angreifer über ein MCP-Tool an personenbezogene Daten, greift die 72-Stunden-Meldefrist an die Aufsichtsbehörde nach Art. 33 DSGVO. Finanzunternehmen in der EU müssen schwerwiegende IKT-Vorfälle zusätzlich nach DORA melden, und die IKT-Risikomanagement-Pflichten erfassen auch solche KI-Komponenten. In der Schweiz verlangt das revidierte Datenschutzgesetz (revDSG) bei Verletzungen mit hohem Risiko eine Meldung an den EDÖB „so rasch als möglich“. Für Software- und Plattformteams in Deutschland, Österreich und der Schweiz heißt das praktisch: Das KI-Gateway gehört ins Asset-Register, ins Schwachstellenmanagement und in die Prüfungen des Informationssicherheits-Managements – nicht in die Grauzone eines PoC.

Checkliste für diese Woche

1. Gateways inventarisieren. Jede LiteLLM-Installation finden – auch Schatten-Deployments in PoCs und Plattform-Namespaces – und Version sowie Verantwortliche erfassen.
2. Auf 1.84.0+ aktualisieren. Alles mit älterer Version und erreichbarem MCP-Streamable-HTTP-Endpunkt patchen und gegen die Frist 16. September prüfen.
3. Endpunkt abschotten. MCP- und Admin-Endpunkte hinter Netzwerkkontrollen und starke Authentifizierung stellen; keine Erreichbarkeit aus nicht vertrauenswürdigen Netzen.
4. Tools nach Least Privilege. Prüfen, was jedes angebundene MCP-Tool erreicht, und auf das Minimum reduzieren, damit eine Umgehung möglichst wenig freilegt.
5. Rotieren und prüfen. Im Gateway hinterlegte Provider-API-Schlüssel rotieren, wenn eine Offenlegung nicht auszuschließen ist, und Logs auf Anfragen mit fehlerhaftem Authorization-Header an der MCP-Route durchsuchen; DSGVO-Meldefrist im Blick behalten.
6. KI-Infrastruktur in den Rhythmus. Gateway- und Framework-Versionen im Schwachstellenmanagement führen, damit die nächste CVE in der KI-Infrastruktur Routine ist.

Häufige Fragen

Quellen

CISA – Known Exploited Vulnerabilities Catalog (Primärquelle, Aufnahme Anfang September 2026)
The Hacker News – CISA Adds Seven Exploited Flaws as Attackers Deploy Reverse Shells and Crypto Miners (September 2026)
GitLab Advisory Database – CVE-2026-59822: LiteLLM MCP Authentication Bypass via OAuth2 Passthrough Fallback