Die erste MCP-CVE auf der KEV-Liste hat ihre föderale Frist erreicht: LiteLLM und der Default-Key-Tresor

CVE-2026-59822 ist ein Authentifizierungsumgehung im LiteLLM-Proxy von BerriAI — das Open-Source-Gateway, das Traffic zwischen Anwendungen und über 100 Modellanbietern routet — und sie hat ihre föderale Frist zur Behebung am 16. September 2026 erreicht. CISA fügte die Schwachstelle am 2. September ihrem Known Exploited Vulnerabilities-Katalog hinzu, mit Fälligkeit heute unter BOD 26-04 — die erste Model Context Protocol-Implementierung, die jemals von einer nationalen Schwachstellenmanagement-Behörde als aktiv ausgenutzt gelistet wurde (NVD; The Hacker News). Die Ausnutzung ist nicht theoretisch: Wiz' Honeypot-Infrastruktur beobachtete CVE-2026-59822 am 7. Juli im Einsatz — 56 Tage vor der KEV-Listung (Wiz). Und die CVE ist nicht einmal der häufigste Weg in diese Gateways. Wiz' Scan vom Februar 2026 über 3.074 internetexponierte LiteLLM-Instanzen fand 294 — 9,6 % — die den in LiteLLMs eigener Dokumentation abgedruckten Beispiel-Master-Key sk-1234 akzeptieren, und 191 mit überhaupt keiner konfigurierten Authentifizierung (Wiz; The Hacker News).

Dieser Artikel deckt vier Dinge ab, die ein Head of Engineering oder Plattform-Verantwortlicher braucht, bevor die nächste Audit eine LiteLLM-Instanz in seinem Netzwerk findet: wie die Umgehung in einer Anfrage funktioniert, warum der Master-Key das Gateway zu einem Cloud-Credential-Tresor macht, was die KEV-Frist tatsächlich verlangt, und die sechs Verifizierungspunkte, die die Exposition schließen — plus das Code-Muster, das aus jedem MCP-Authentifizierungshandler verbannt gehört, den Sie besitzen.

Kernpunkte

• CVE-2026-59822 ist die erste MCP-spezifische CVE auf CISA's KEV-Liste — hinzugefügt am 2. September 2026 mit einer föderalen Frist zur Behebung am 16. September 2026, bei CVSS 8.8, und betrifft alle LiteLLM-Versionen vor 1.84.0.
• Wiz' Honeypot beobachtete die Ausnutzung am 7. Juli 2026 — 56 Tage vor der KEV-Listung — mit einem Bearer-Token aus einem einzigen Zeichen, das eine voll authentifizierte MCP-Sitzung etablierte.
• 294 von 3.074 internetexponierten LiteLLM-Gateways (9,6 %) akzeptieren den dokumentierten Beispiel-Master-Key sk-1234 oder keine Authentifizierung — 191 davon verlangen keinerlei Credential, laut Wiz' Shodan-Scan vom Februar 2026.
• Der Master-Key ist ein Cloud-Credential-Tresor: Ein gültiger Administrator (oder ein Angreifer im Besitz des Keys) kann Pass-Through-Routing nutzen, um AWS-Instanz-Metadaten zu lesen und IAM-Credentials abzurufen, und IMDSv2 stoppt das nicht, weil der Proxy x-pass--präfixierte Header weiterleitet.
• Die Umgehung ist ein Code-Muster, nicht nur ein Bug: Eine fehlgeschlagene Authentifizierung abfangen und ein leeres Auth-Objekt einsetzen. Die in ACM publizierte „Puppet"-Forschung zeigt, dass diese Confused-Deputy-Klasse bis zu 90,89 % Erfolg beim Tool-Selection-Hijacking erreicht — unsichtbar für MCP-Scan und McpSafetyScanner.

Die 24-Stunden-Uhr, und wie die Umgehung in einer Anfrage funktioniert

Die Zeitlinie zählt, weil sie zeigt, dass die Ausnutzung in jeder Phase der föderalen Reaktion voraus war. Wiz meldete die Schwachstelle am 18. Februar 2026 an die LiteLLM-Maintainer; der Fix erschien am 25. April in LiteLLM 1.84.0; Wiz' Honeypot zeichnete reale Ausnutzung am 7. Juli auf; die Schwachstelle wurde am 8. Juli veröffentlicht; CISA fügte sie am 2. September dem KEV-Katalog hinzu — und setzte die Frist zur Behebung 14 Tage später an (Wiz; NVD).

Der Mechanismus ist ein Fail-Open-Fallback in LiteLLMs MCP-Endpoint. Der Endpoint unterstützt zwei Authentifizierungsmuster: native LiteLLM-Keys und OAuth2-Tokens, die an einen vorgelagerten MCP-Server durchgereicht werden. Wenn ein Bearer-Token die LiteLLM-Key-Validierung mit 401 oder 403 fehlschlägt, sollte der Handler den Token an das Upstream weiterleiten. Stattdessen fängt er den Fehler ab und gibt ein leeres UserAPIKeyAuth()-Objekt zurück — eine authentifizierte Sitzung ohne Identität dahinter (Wiz; GitLab-Advisory-Datenbank). Wiz' Demonstration nutzte Authorization: Bearer *** — ein einzelnes Zeichen — und erhielt HTTP 200 mit einer gültigen mcp-session-id`.

Was diese Sitzung erreichen kann, hängt vollständig von der Deployment-Konfiguration ab. Ein Gateway mit angeschlossenem Datenbankabfrage-Tool überlässt dem Angreifer Abfragezugriff; die GitHub-Integration überlässt Repository-Lesezugriff und Issue-Erstellung; Filesystem-Konnektoren überlassen Lese-Schreib-Zugriff. Das von LiteLLM dokumentierte allow_all_keys-Flag — von LiteLLM selbst für „Low-Risk-Utilities" empfohlen — macht jeden konfigurierten MCP-Server für das leere Credential erreichbar, das die Umgehung erzeugt (Hive Security). Der Blast-Radius ist nicht der Proxy. Er ist jedes System, das die MCP-Server des Proxys berühren.

Drei Ausfälle, ein Gateway

Wiz' Forschung förderte vier distinkte Probleme in LiteLLM mit unterschiedlichen Vorbedingungen zutage — sie zu einer „Magic Chain" zusammenzupressen verfälscht sowohl die Schwere als auch die Reaktion (Wiz):

1. CVE-2026-59822 — die MCP-Authentifizierungsumgehung. Ohne Authentifizierung, eine Anfrage, Versionen vor 1.84.0. Gefixt in 1.84.0.
2. CVE-2026-59821 — Root-Level-Code-Ausführung über Custom Guardrails. Der Guardrail-Registrierungs-Endpoint reichte von Administratoren übermitteltes Python an exec() durch, ohne die Sandbox (Builtins-Stripping, verbotene Muster-Checks), die auf dem UI-Testpfad angewandt wird. Wiz beobachtete Code, der als root im Proxy-Container lief. Gefixt in 1.82.0-stable. Dieser erforderte Admin-Zugang — aber kombiniert mit Ausfallmodus 3 wird er effektiv pre-auth.
3. Default oder fehlende Authentifizierung. Das Ergebnis des 294-von-3.074-Scans. Wenn kein Master-Key konfiguriert ist, gewährte LiteLLM jedem Aufrufer PROXY_ADMIN-Zugriff — ein Designverhalten ohne CVE, das zusammen mit CVE-2026-59821 gefixt wurde.
4. Pass-Through-Routing zu Cloud-Metadaten. Ein authentifizierter Administrator kann eine Pass-Through-Route auf den AWS-Instanz-Metadatenservice richten und den IMDSv2-Session-Token-Header durch das x-pass--Prefix-Stripping des Proxys weiterleiten. Wiz und LiteLLM klassifizieren dies als beabsichtigtes Administratorverhalten — keine CVE, kein Fix. Aber sobald ein Default- oder geleakter Master-Key die Annahme auslöscht, dass nur vertrauenswürdige Administratoren den Key halten, wird diese „beabsichtigte" Fähigkeit zum Weg von der Anwendungskompromittierung zur Cloud-Account-Kompromittierung (CSA).

Die Verkettung ist die Story. LiteLLM hält API-Keys jedes konfigurierten Modellanbieters — OpenAI, Anthropic, AWS Bedrock, Azure, Google Vertex AI — und etwa ein Drittel der befragten Cloud-Umgebungen betreibt eine Bereitstellung (CSA). CSA's Research Note nennt die Master-Key-Konfiguration „einen Cloud-Credential-Tresor". Der Tresor wurde bereits einmal geleert: In einer öffentlich gemeldeten Kompromittierung im August 2026 las ein Angreifer mit Code-Ausführung auf einem Gateway-Host die Umgebungsvariablen des Containers, erlangte den Master-Key und einen Datenbank-Connection-String zurück und kopierte Datensätze direkt aus der PostgreSQL-Datenbank, die das Gateway trägt (CSA).

Eine gepatchte Instanz ist keine sichere Instanz. Ein auf 1.84.0 gepatchtes Gateway, das weiterhin sk-1234 beantwortet, ist kompromittiert für jeden, der den Default kennt — das ist jeder, der das README gelesen hat.

Was die KEV-Listung tatsächlich verlangt

Der Known Exploited Vulnerabilities-Katalog ist kein Severity-Ranking. Er ist ein Befund aktiver Ausnutzung mit bindender Uhr: Unter BOD 26-04 müssen föderale Zivilbehörden bis zum Fälligkeitsdatum Anbieter-Mitigationen anwenden oder die Nutzung des Produkts einstellen, und die Behörden müssen internetexponierte Instanzen zuerst triagen. Die heute fällige Frist gilt direkt für föderale Behörden — aber ihre Wirkung reicht weiter, weil eine wachsende Zahl von Cyber-Versicherungen und Vendor-Risk-Fragebögen den KEV-Katalog als Baseline referenzieren (Tech Insider). Eine ungepatchte CVE-2026-59822-Instanz ist jetzt ein Audit-Befund für jede Organisation, deren Compliance-Regime die KEV-Liste erbt — ob föderale Behörde oder nicht.

Der Meilenstein zählt für das Protokoll, nicht nur für das Produkt. CVE-2026-42271 — LiteLLMs Testing-Endpoint-Command-Injection, in einem früheren Batch zur KEV hinzugefügt — war MCP-adjacent. CVE-2026-59822 ist MCP-spezifisch: Die ausgenutzte Oberfläche ist der MCP Streamable HTTP-Endpoint und sein Authentifizierungshandler. Die erste MCP-Schwachstelle mit föderalem Behebungsauftrag signalisiert, woher die nächsten kommen. UltraViolet Cyber's Threat Advisory zählt allein für 2026 über 40 CVEs, die gegen MCP-Implementierungen offengelegt wurden (UltraViolet Cyber), Bitsight's Internet-Scan fand rund 1.000 exponierte MCP-Server, die vollständige Tool-Inventare ohne Autorisierung anbieten (Bitsight), und Practical DevSecOps maß, dass 30–82 % der öffentlichen MCP-Server ausnutzbare Mängel tragen (Practical DevSecOps). Der Expositionsstapel hinter der ersten KEV-Listung ist kein Ausreißer. Er ist die Population.

Das Diagramm unten komprimiert den Vorfall in eine Minute: die Zeitlinie, die der föderalen Reaktion voraus war, die vier Ausfallmodi, die sich ein Gateway teilen, und die sechs Verifizierungspunkte, die die Exposition schließen.

Die sechs Verifizierungspunkte

Die MCP-Sicherheits-Hardening-Checkliste, die der Elternartikel auf 12 Kontrollen destilliert, erhält nun ein Gateway-spezifisches Supplement. Sechs Punkte, jeder in Minuten verifizierbar:

1. Beweisbar fail-closed. Sende Authorization: Bearer *** an den /mcp/`-Endpoint des Gateways. Eine korrekt konfigurierte Instanz antwortet mit 401 oder 403. Eine verwundbare Instanz antwortet mit 200 und einer Session-ID. Das ist der CVE-2026-59822-Test — und er braucht eine Anfrage.
2. Inventarisieren und upgraden. Finde jede LiteLLM-Instanz — inklusive Shadow-Deployments in Entwickler-Stacks —, protokolliere Version und Image-Digest und pinne eine aktuelle Stable fest. 1.84.0 fixte zuerst CVE-2026-59822; 1.82.0-stable fixte CVE-2026-59821; es gibt spätere Advisories — friere also auf keinem der beiden Minima ein (Hive Security). Wenn ein sofortiges Upgrade unmöglich ist, ist die Übergangsmitigation des Advisory das Blockieren von /mcp/ und verwandten Routen am Edge.
3. Rotiere den Master-Key und alles dahinter. Ersetze sk-1234 und jeden wiederverwendeten Key. Bei vermuteter Exposition oder verdächtigem Zugriff rotiere Modell-Provider-, Datenbank-, OAuth- und MCP-verbundene Service-Credentials und widerrufe abgeleitete Sitzungen — die dokumentierte Kompromittierungskette zeigt, dass eine Gateway-Kompromittierung direkt in einen Provider-Key-Leak und einen Datenbank-Dump kaskadiert (CSA).
4. Begrenze den MCP-Tool-Zugriff. Entferne allow_all_keys aus sensiblen Integrationen, trenne Lese- von Schreib-Tools und verlange Team-spezifische Autorisierung. Die Umgehung gewährt alles, was die Sitzung erreichen kann — die Tool-Konfiguration ist der Blast-Radius.
5. Enthalte die Control-Plane. Entferne öffentliche Exposition, außer explizit erforderlich; verweige Workloads den Zugriff auf Cloud-Metadatendienste; lege Egress-Ziele auf Allowlist; und betreibe den Container als non-root ohne privilegierte Mounts. IMDSv2 verteidigt diesen Pfad nicht, weil der Proxy die Token-Anfrage selbst stellen und die Header weiterleiten kann (Wiz).
6. Durchsuche die Logs, bevor sie ablaufen. Prüfe Reverse-Proxy- und LiteLLM-Logs auf /mcp/-Sitzungen mit junk-artigen Tokens, unerwartete Tool-Aufrufe, Guardrail-Erstellungsereignisse und Pass-Through-Konfigurationsänderungen. Korreliere mit Prozess-, DNS- und Cloud-Audit-Logs — und sichere die Beweise vor dem Neustart, denn ein Neustart löscht den In-Memory-Zustand, widerruft aber kein gestohlenes Credential (Hive Security).

Punkte 1 und 3 sind die Frist-Tages-Priorität: Der erste beweist die Schwachstelle, der zweite schließt die Dauerexposition, die jeden Patch überlebt.

Was das über LiteLLM hinaus bedeutet

Zwei Muster verallgemeinern, und beide gehören ab jetzt in jede MCP-Authentifizierungsprüfung.

Erstens: Fail-Open-Fallbacks sind ein Code-Smell, kein LiteLLM-Bug. Die Umgehung sind drei Zeilen — den 401 abfangen, ein leeres Auth-Objekt einsetzen, fortfahren. Jeder MCP-Proxy, der Authentifizierung über einen Passthrough-Fallback an einen Upstream-Provider delegiert, trägt dieselbe Klasse. Der Fix ist ein Review-Standard, kein Version-Bump: Wenn die Upstream-Validierung fehlschlägt, terminiert die Anfrage. Sie fährt nie mit einer nicht authentifizierten Identität fort.

Zweitens: Gateways sind Control-Planes, und Confused-Deputy-Forschung sagt, dass sie auf der Metadatenebene scheitern. Die in ACM publizierte „Puppet"-Forschung evaluierte Confused-Deputy-Angriffe über 14 Modelle auf 2 MCP-Hosts und maß Tool-Selection-Hijacking-Raten bis zu 90,89 % und End-to-End-Payload-Ausführung bis zu 86,46 % — während sie für MCP-Scan und McpSafetyScanner unerkennbar blieb, die architektonisch unfähig sind, Manipulationen auf Metadatenebene zu erfassen (ACM). Ein Gateway, das Modell-Credentials, Prompt-Sichtbarkeit und Tool-Zugriff hinter einer einzigen Authentifizierungsgrenze konzentriert, ist dieselbe Konzentration, die CSA's AI Controls Matrix für Identitäts- und Secrets-Management-Kontrollen markiert (CSA). Die operative Übersetzung: Authentifiziere das Gateway wie eine Control-Plane und enthalte es wie eine Kompromittierungsgrenze — Least-Privilege-IAM, keine Default-Credentials, Metadaten unerreichbar, Egress-Allowlist.

Der breitere Kontext ist ein Protokoll, das von „optionaler Autorisierung" zu föderaler Durchsetzung reift. Bitsight's Scan vom Dezember 2025 fand rund 1.000 exponierte MCP-Server ohne Autorisierung (Bitsight); Wiz' Honeypot-Analyse vom August 2026 dokumentierte aktive Kampagnen gegen LiteLLM, MCP-Server und AI-Frameworks durch RCE, blinde Prompt-Injection und In-Memory-Credential-Diebstahl (Wiz); und eine dritte LiteLLM-Authentifizierungsumgehung — CVE-2026-49468, eine am 28. Mai 2026 offenlegte Host-Header-Injection — komplettiert ein 2026er-Muster, in dem dasselbe Produkt drei distinkte Authentifizierungsausfälle in einem Jahr auslieferte (GitHub-Advisory). Die KEV-Listung ist der Punkt, an dem dieses Muster aufhört, ein Forschungsthema zu sein, und ein Compliance-Posten wird.

Die MCP-Spezifikation vom 2026-07-28 bewegte das Protokoll zu einem zustandslosen Kern, und die Autorisierungsarbeit des Ökosystems bewegt sich auf OAuth 2.1 mit audience-gebundenen Tokens zu. Architektur schließt ganze Schwachstellenklassen. Aber der LiteLLM-Vorfall beweist, dass die Betriebsschicht die Ergebnisse entscheidet: Eine zustandslose, spezifikationskonforme Bereitstellung, die ihren Beispiel-Master-Key weiterhin akzeptiert, bleibt kompromittiert. Patche die CVE, dann auditiere die Defaults — in dieser Reihenfolge, vor der nächsten Frist.

Weiterführende Literatur

• MCP-Sicherheits-Hardening-Checkliste: 1.467 exponierte Server und die Kontrollen, die sie schließen — der Elternartikel: 12 Hardening-Kontrollen über Transport, Authentifizierung, Tool-Registrierung, Runtime und Audit, jede in unter fünf Minuten verifizierbar
• Das MCP-Paradox: Warum nahtlos fragil ist — die Protokoll-Level-Risikoanalyse: warum ein Standard, der Integration nahtlos macht, gleichzeitig den Kompromittierungs-Blast-Radius konzentriert
• MCP 2026-07-28: Was das zustandslose Protokoll für B2B-Agenten-Deployments bedeutet — der zustandslose Protokollkern, der die Sitzungszustands-Angriffsflächen eliminiert, die diese CVE-Klasse ausnutzt

---

Ein Mid-Market-Distributor betreibt einen Beschaffungsagenten, der gegen NetSuite, BigCommerce und drei Lieferantenkataloge kalkuliert, wobei ein LiteLLM-Gateway den Modellverkehr routet und die MCP-Tools des Agenten exponiert. Eine Ein-Anfragen-Verifizierung gegen /mcp/ beweist, dass das Gateway fail-closed ist; der Master-Key kommt aus dem Secret-Manager, nie aus dem README; die IAM-Rolle des Gateways kann die Instanz-Metadaten nicht erreichen; und die MCP-Tools, die der Agent aufrufen kann, sind auf das Lesen von Preisen und Schreiben von Angeboten begrenzt — nichts anderes. Wenn die nächste KEV-Listung kommt, ist die Remediation ein Version-Bump, keine Kompromittierungsuntersuchung.

Beauftragen Sie einen abgegrenzten Build. Einwöchige Discovery. Sie erhalten ein Systeminventar, eine Workflow-Karte und einen festen Umfang — unabhängig davon, ob Sie mit uns bauen.