CISA nimmt LiteLLMs MCP-Auth-Bypass in KEV auf: Jeder beliebige Bearer-Token genügte

Am 2. September 2026 nahm die U.S. Cybersecurity and Infrastructure Security Agency CVE-2026-59822 als „BerriAI LiteLLM Improper Authentication Vulnerability“ in ihren Katalog der bekannten ausgenutzten Schwachstellen (Known Exploited Vulnerabilities) auf, eine von sieben Schwachstellen im Paket jenes Tages. Der Fehler liegt im MCP-Streamable-HTTP-Endpunkt von LiteLLM: Wenn die Validierung eines LiteLLM-Schlüssels fehlschlug, setzte der OAuth2-Passthrough-Fallback ein leeres UserAPIKeyAuth()-Objekt ein, anstatt die Anfrage abzulehnen, sodass jeder gefälschte Authorization-Bearer-Header eine authentifizierte MCP-Sitzung öffnete. Ein Angreifer, der diesen Endpunkt erreichte, konnte jedes MCP-Tool auflisten und aufrufen, mit dem das Gateway konfiguriert war, und über diese Tools die dahinterliegenden Dienste erreichen. Alle Versionen vor 1.84.0 sind betroffen, und den zivilen Bundesbehörden wurde bis zum 16. September Zeit zur Behebung gegeben. Dieser Datensatz – die KEV-Auflistung für die MCP-Authentifizierungsumgehung von LiteLLM – ist ein Eintrag in dem OrcaRouter AI Incident Archive, das den vollständigen Datensatzbestand und die benachbarten Einträge dieses Vorfalls enthält.

Der Grund, warum ein Fehler in einem Proxy wichtiger ist, als es sein CVSS-Score vermuten lässt, liegt in dem, was hinter dem Proxy steht. Das Threat-Research-Team von Wiz bringt es auf den Punkt: „Ein LiteLLM-Proxy kann Schlüssel für jeden Modellanbieter enthalten, an den er weiterleitet, einschließlich OpenAI, Anthropic, Azure und Gemini. Er kann außerdem mit Cloud-IAM-Berechtigungen laufen und über MCP-Tool-Server eine Verbindung zu internen Diensten herstellen. Eine einzige Kompromittierung kann einem Angreifer Zugriff auf die Anmeldedaten und Dienste verschaffen, die dem Proxy nachgelagert sind – nicht nur auf den Proxy selbst.“ Wiz Research gibt an, die Schwachstelle entdeckt zu haben, und die Honeypots von Wiz verzeichneten später Versuche, sie auszunutzen.

Der Mechanismus: eine fehlgeschlagene Prüfung, die eine gültige Sitzung zurückgab

BerriAIs eigener Sicherheitshinweis, GHSA-7488-6r32-c95q, beschreibt den Fehler in zwei Sätzen: „Der MCP-Auth-Handler unterstützte OAuth2-Passthrough für vorgelagerte MCP-Server, aber der Fallback-Pfad konnte eine fehlgeschlagene LiteLLM-Schlüsselvalidierung durch ein leeres UserAPIKeyAuth()-Objekt ersetzen. Dadurch konnten Anfragen mit einem gefälschten Authorization-Header die MCP-Tooling erreichen, ohne einen gültigen LiteLLM-Schlüssel.“ Das entscheidende Wort lautet Fallback. Der Code hatte einen Zweig für Deployments, die das OAuth-Token eines vorgelagerten MCP-Servers direkt durchreichen, und wenn ein LiteLLM-Schlüssel die Validierung nicht bestand, gab dieser Zweig ein leeres Authentifizierungsobjekt statt eines Fehlers zurück.

Ein leeres Authentifizierungsobjekt ist nicht dasselbe wie kein Authentifizierungsobjekt. Downstream-Code erhielt ein erfolgreich konstruiertes UserAPIKeyAuth und machte weiter, ohne dass ein Tenant, ein Benutzer oder ein Scope daran hing. Wiz' Bericht ist unverblümter, was die praktische Konsequenz angeht: „Wenn die Token-Validierung fehlschlägt, lehnt der Server die Anfrage nicht ab, sondern gibt ein leeres UserAPIKeyAuth()-Objekt ohne Einschränkungen zurück. Jedes Bearer-Token (sogar ein einzelnes Zeichen, z. B. x) gewährt vollen MCP-Zugriff.“

Was ein Angreifer dadurch erhält, ist eine Art Menü. Das MCP-Protokoll stellt eine Auflistung der Tools bereit, sodass eine authentifizierte Sitzung die Namen und Schemas jedes Tools zurückliefert, das das Gateway erreichen soll – Datenbanken, Code-Repositories, interne APIs in den Beispielen von Wiz. Die Sicherheitsmeldung des Anbieters beschreibt die Auswirkung unverblümt: „Ein Angreifer könnte dies nutzen, um konfigurierte MCP-Tools aufzulisten und aufzurufen und auf verbundene Dienste zuzugreifen, die über MCP bereitgestellt werden." Die Tool-Aufrufe werden dann mit derjenigen Berechtigung ausgeführt, die der Proxy selbst gegenüber diesen Backends besitzt – das ist das Problem der Konzentration von Zugangsdaten, das Wiz beschreibt.

Ein Fix im Mai, eine CVE im Juli, eine Frist auf Bundesebene im September

Die Daten passen nicht so zusammen, wie ein Leser vielleicht annehmen würde, und die Lücken sind das Interessante. LiteLLM 1.84.0 – die erste Version, die der Sicherheitshinweis als gepatcht nennt – wurde laut den Release-Metadaten des Paketindex selbst am 14. Mai 2026 auf PyPI hochgeladen. Die CVE-Kennung wurde am 7. Juli 2026 beim CVE Program reserviert und der Eintrag am folgenden Tag, dem 8. Juli, veröffentlicht; der OSV-Eintrag PYSEC-2026-3479 folgte am 23. Juli. Die KEV-Aufnahme erfolgte am 2. September, mit einer Frist zur Behebung bis zum 16. September.

Daraus folgen zwei Dinge. Erstens war der gepatchte Build mehr als drei Monate lang öffentlich, bevor CISA die Schwachstelle als ausgenutzt listete – die Organisationen, für die die Frist galt, hatten also die ganze Zeit über ein funktionierendes Upgrade zur Verfügung, und die KEV-Aufnahme war nicht der Moment, in dem ein Fix erschien. Zweitens hat sich die Versionslücke seitdem vergrößert: Die aktuelle LiteLLM-Version auf PyPI ist 1.106.5, hochgeladen am 27. Oktober 2026. Ein Deployment, das noch auf einer Version unter 1.84.0 steht, liegt nun mehr als zwanzig Minor-Releases zurück, nicht nur einen Patch.

Was das Inserat belegt – und was nicht

Die CISA-Warnung zu dieser Charge besagt, dass die Ergänzungen „aufgrund von Hinweisen auf aktive Ausnutzung“ vorgenommen wurden, und der maschinenlesbare Eintrag des Katalogs für CVE-2026-59822 enthält ein Aufnahmedatum vom 2. September 2026, ein Fälligkeitsdatum vom 16. September 2026, einen Wert für die Nutzung in bekannten Ransomware-Kampagnen von „Unknown“ sowie zwei Schwachstellen: CWE-287 (unsachgemäße Authentifizierung) und CWE-306 (fehlende Authentifizierung für eine kritische Funktion).

• Festgestellt: CISA stufte die Schwachstelle als aktiv ausgenutzt ein und setzte sie auf die bundesweite Liste der zu behebenden Schwachstellen. Der SSVC-Eintrag von NVD, der einem CISA-Koordinator zugeschrieben und mit Zeitstempel vom 2. September 2026 versehen ist, verzeichnet die Ausnutzung als „aktiv“, die Automatisierbarkeit als „ja“ und die technische Auswirkung als „teilweise“.

• Bestätigt:Ausnutzung wurde in einer kontrollierten Umgebung beobachtet. Wiz veröffentlichte Honeypot-Traffic, der Anfragen mit Ein-Zeichen-Tokens zeigt, die einen Model-Enumeration-Endpunkt sondieren: ein GET auf /v1/models mit „Authorization: Bearer x“. The Hacker News berichtete am 3. September über den KEV-Batch und beschrieb dieselbe Aktivität als Beobachtung von Wiz: „Ausnutzungsversuche unter Beteiligung von CVE-2026-59822 gegen seine Honeypots, um Endpunkte zur Model-Enumeration zu sondieren“.

• Festgestellt: Die Schweregradbewertungen existieren beide und unterscheiden sich je nach Framework. BerriAIs Advisory bewertet die Schwachstelle nach CVSS 4.0 mit 8,8 (hoch), wobei Vertraulichkeit hoch, Integrität niedrig und Verfügbarkeit keine ist; NISTs eigene CVSS-3.1-Bewertung, die in NVD maßgeblich ist, setzt sie auf 8,2. Die beiden Zahlen beschreiben denselben Defekt unter unterschiedlichen Bewertungssystemen und sollten nicht so verglichen werden, als ob eine die andere abgelöst hätte.

• Nicht belegt: ein namentlich genanntes Opfer. Weder der Alarm von CISA noch die Warnmeldung von BerriAI noch der Bericht von Wiz noch die Berichterstattung von The Hacker News identifiziert eine Organisation, deren MCP-Tools über diese Schwachstelle erreicht wurden, oder berichtet von Zugangsdaten oder Daten, die von einer solchen entwendet wurden. Der öffentliche Beleg für eine Ausnutzung sind Honeypot-Telemetrie und eine Feststellung einer Bundesbehörde, nicht eine offengelegte Sicherheitsverletzung.

• Nicht belegt: dass keine Ransomware-Gruppe sie nutzt. Im KEV-Feld steht „Unknown“ – ein von CISA vergebener Wert und kein Befund, der in die eine oder andere Richtung auf Abwesenheit schließen lässt.

Der Präzedenzfall vom Juni – und die Remote-Code-Execution-Kette, die dies nicht ist

Dies ist die zweite LiteLLM-Schwachstelle, die 2026 in den KEV-Katalog aufgenommen wurde, und die frühere ist leicht mit ihr zu verwechseln. CVE-2026-42271, am 8. Juni 2026 mit einer Frist zum 22. Juni hinzugefügt, ist eine Befehlsinjektion in LiteLLMs MCP-Server-Testendpunkten: Wiz beschreibt Endpunkte, mit denen ein Benutzer eine MCP-Server-Konfiguration testen kann, bevor er sie speichert, wobei das Feld command ohne Validierung an die Subprozessausführung übergeben wird. Angreifer reichten eine gefälschte stdio-Server-Konfiguration ein, deren Befehl einen Kryptominer herunterlud und ausführte, und gaben einen gültig aussehenden MCP-Handshake zurück, sodass der Test erfolgreich zu sein schien. CISAs Eintrag dafür listet CWE-78 und CWE-77 auf — Befehls- und Argumentinjektion, nicht Authentifizierung.

Dieser Fehler ist derjenige, der sich verketten lässt. Wiz sagt, CVE-2026-42271 lasse sich „mit einer Umgehung der Host-Header-Validierung von Starlette (CVE-2026-48710) verketten, um eine vollständig unauthentifizierte RCE zu erreichen“, und externe Forscher hätten die Qilin-Ransomware-Gruppe mit der aktiven Ausnutzung dieser Kette in Verbindung gebracht. CVE-2026-48710 wurde im selben Batch vom 2. September wie der LiteLLM-Bypass in den KEV-Katalog aufgenommen, mit derselben Frist vom 16. September, und der Katalogeintrag von CISA zu der Starlette-Schwachstelle selbst besagt, dass sie sich mit CVE-2026-42271 verketten lasse. Die Verbindung zu Qilin gehört zu dieser Paarung. Sie ist keine Erkenntnis zu CVE-2026-59822, und nichts in den geprüften Quellen verbindet die Ransomware-Gruppe mit der Umgehung der Authentifizierung.

Ein administratives Detail unterscheidet die beiden LiteLLM-Einträge: Die erforderliche Maßnahme im Juni-Eintrag verweist auf BOD 22-01, die ältere bindende operative Direktive, während der September-Eintrag BOD 26-04 zitiert, „Prioritizing Security Updates Based on Risk“. Die CISA-Warnung erklärt die Änderung nicht, und der Katalog kommentiert sie nicht.

Was hat sich danach geändert

Der Behebungsweg ist kurz. BerriAIs Sicherheitshinweis empfiehlt ein Upgrade auf 1.84.0 oder höher und bietet einen Workaround für Teams, die nicht sofort umstellen können: „MCP-Routen deaktivieren oder den Zugriff auf /mcp/ und zugehörige MCP-Endpunkte an Ihrem Reverse Proxy oder API Gateway blockieren.“ Dieser Workaround ist ein grobes Mittel – er entfernt die Funktion, statt sie abzusichern –, aber er ist die einzige Gegenmaßnahme, die der Anbieter für ungepatchte Installationen nennt.

Der von CISA formulierte Text zu den erforderlichen Maßnahmen für die Einstiegspunkte stellt Bundesbehörden vor denselben Zielkonflikt: Minderungsmaßnahmen gemäß den Herstelleranweisungen und im Einklang mit BOD 26-04 anzuwenden, „oder die Nutzung des Produkts einzustellen, wenn keine Minderungsmaßnahmen verfügbar sind“, wobei jede Behörde dafür verantwortlich ist, die Internetexposition eines Assets zu bewerten. Die Richtlinie ist nur für Bundesbehörden der zivilen Exekutive bindend; CISA ermutigt andere Organisationen, dieselbe risikobasierte Priorisierung zu übernehmen, ohne sie dazu zu verpflichten.

Ob jemand außerhalb eines Honeypots bis zur Frist tätig geworden ist, ist nicht öffentlich. Weder CISA noch BerriAI haben Zahlen dazu veröffentlicht, wie viele LiteLLM-Deployments exponiert waren, wie viele vor dem 16. September gepatcht wurden oder wie viele über die Umgehung erreicht wurden.

Was offen bleibt

Drei Lücken sollten benannt statt übergangen werden. Es gibt keinen öffentlichen Vorfallbericht, der CVE-2026-59822 mit einer bestimmten Intrusion in Verbindung bringt, sodass die KEV-Listung auf CISA-Belegen zur Ausnutzung und Wiz' Honeypot-Beobachtungen beruht statt auf einem dokumentierten Opfer. Es gibt keine Herstellererklärung dazu, wie es dazu kam, dass der Fallback-Pfad so geschrieben wurde, oder wie lange er vor 1.84.0 existierte – die Sicherheitsmeldung beschreibt den Defekt und seine Behebung, nicht seine Vorgeschichte. Und die Fristen des Batches waren nicht einheitlich: Fünf der sieben am 2. September hinzugefügten Einträge hatten eine Frist bis zum 5. September, während die LiteLLM- und Starlette-Einträge den 16. September hatten. CISA sagt nicht, warum.

Was feststeht, ist enger und nützlicher als der Score. Ein einzelnes Zeichen in einem Authorization-Header war auf den betroffenen Versionen nicht von einem gültigen Schlüssel für den MCP-Endpunkt zu unterscheiden — und die Versionen, die sich so verhielten, waren seit Mai 2026 nicht mehr aktuell.