AI-Gateways werden zur Angriffsfläche — die KEV-Aufnahme von LiteLLM und der Pfad durch Schlüssel, MCP und die Cloud
Der MCP-Authentication-Bypass von BerriAI LiteLLM (CVE-2026-59822) ist im KEV-Katalog von CISA gelandet, und Microsoft berichtet, dass Angreifer LiteLLM-Gateways nutzen, um XMRig auszuliefern. Die Forschung von Wiz fand, dass etwa 1 von 10 der ~3,000 öffentlichen Instanzen den Standardschlüssel sk-1234 akzeptierte oder ohne Authentifizierung lief. Wir untersuchen, was es bedeutet, dass AI-Infrastruktur ein Tresor für Zugangsdaten ist.
Dieser Artikel wurde maschinell übersetzt.
Im September 2026 hat CISA den MCP-Authentication-Bypass von BerriAI LiteLLM, CVE-2026-59822, in seinen Katalog Known Exploited Vulnerabilities (KEV) aufgenommen (2. September, gemäß der Zeitleiste von Wiz). Die Schwachstelle lässt ein beliebiges Bearer-Token eine gültige authentifizierte Sitzung auf dem Endpunkt MCP Streamable HTTP von LiteLLM herstellen, und sie erschien neben sechs weiteren ausgenutzten Schwachstellen — darunter SonicWall SMA 1000 und Sangoma Switchvox — im KEV-Update Anfang September (laut The Hacker News). LiteLLM ist ein Open-Source-AI-Gateway, das die API-Schlüssel für jeden konfigurierten LLM-Anbieter hält; nach Schätzung von Wiz ist es in etwa einem Drittel der Cloud-Umgebungen vorhanden.
Die Fakten: (1) Die Forschung von Wiz (veröffentlicht am 9. September) fand, dass von etwa 3,000 internetseitigen LiteLLM-Instanzen rund 9.6% den Standard-Master-Key sk-1234 akzeptierten oder überhaupt keine Authentifizierung verlangten. In Instanzen ohne konfigurierte Authentifizierung erhielt jeder Benutzer standardmäßig PROXY_ADMIN und erreichte Admin-Funktionalität ohne Zugangsdaten (inzwischen behoben). (2) Mit Admin-Rechten kann ein Angreifer die Funktion Pass-through-Endpoint nutzen, um Anfragen an beliebige interne URLs zu vermitteln — einschließlich des Metadaten-Dienstes von AWS — und der Mechanismus zur Weiterleitung von Headern x-pass- hebt die Anforderung eines Session-Tokens von IMDSv2 auf und ermöglicht den Diebstahl von Cloud-IAM-Zugangsdaten. (3) Im September berichtete Microsoft, dass Angreifer CVE-2026-42271 und CVE-2026-48710 (den Authentication-Bypass 'BadHost' von Starlette) verketteten, um in LiteLLM-Gateways einzubrechen und einen XMRig-Miner über ein ELF-Binary auszuliefern (laut The Hacker News). Angriffe auf exponierte RAGFlow-Instanzen erbrachten unterdessen gestohlene Schlüssel von LLM-Anbietern und Metadaten, nicht Ransomware.
Analyse (von den Fakten getrennt): Was diese Geschichten zeigen, ist, dass AI-Gateways die Stufe des 'LLMjacking' hinter sich gelassen haben — das Ausgeben des API-Budgets eines anderen — und zu einem regelrechten Pfad des Eindringens in die Cloud geworden sind. LiteLLM führt bei jeder Inferenzanfrage serverseitiges Python aus, kann Anfragen an beliebige interne URLs vermitteln und verbindet sich über MCP mit externen Werkzeugen. Es ist nicht bloß ein Tresor für Schlüssel; es ist eine Brücke in das interne Netz mit der Fähigkeit zur Ausführung. Assets, die Verteidiger unter einem Entwurfsgrundsatz 'es ist AI, behalte es intern' lieber beiseitelegen, werden für Angreifer zu einem mehrstufigen Pfad zu Schlüsseln, IAM und internen APIs hinter einem einzelnen Authentication-Bypass. Die strukturelle Lücke zwischen Defaults, die für die Erfahrung von Entwicklern entworfen sind (sk-1234, PROXY_ADMIN wenn unkonfiguriert), und dem Einsatz in der Produktion verdient es, als solche benannt zu werden.
Abwehrseitige Folgerungen: (1) Wenn Sie LiteLLM betreiben, aktualisieren Sie zuerst auf v1.84.0 oder später (Fix für CVE-2026-59822) und auf v1.83.7 oder später (Fix für CVE-2026-42271), dazu Starlette 1.0.1 oder später; bestätigen Sie, dass der Standard-Master-Key geändert wurde und die Instanz nicht zum Internet hin exponiert ist. (2) Rotieren Sie alle gespeicherten API-Schlüssel von Anbietern so, als wären sie kompromittiert, sobald die Exposition bestätigt ist, und setzen Sie Ausgabengrenzen, um den Schaden zu begrenzen, wenn ein Schlüssel doch abwandert. (3) Behandeln Sie Funktionen, die beliebige Codeausführung oder die Vermittlung beliebiger URLs mit sich bringen — MCP, Pass-through-Endpoints — als Berechtigungen auf der Ebene eines Agenten, die gesondert zu inventarisieren und standardmäßig abzuschalten sind. (4) Prüfen Sie andere AI-Gateways und LLM-Orchestratoren mit demselben Blick: Standard-Zugangsdaten, exponierte Admin-Funktionalität, Vermittlung interner URLs. Dies ist unsere Analyse, nicht eine Anleitung des Herstellers.
Die Fakten in diesem Artikel stammen vorrangig aus der Forschung von Wiz (https://www.wiz.io/blog/off-guard-breaking-litellm-from-authentication-bypass-to-cloud-compromise), dem Fix-Release von BerriAI LiteLLM (https://github.com/BerriAI/litellm/releases/tag/v1.83.7-stable) und dem KEV-Katalog von CISA (https://www.cisa.gov/known-exploited-vulnerabilities-catalog), mit der Berichterstattung von The Hacker News als sekundärer Quelle (https://thehackernews.com/2026/09/cisa-adds-5-actively-exploited.html und https://thehackernews.com/2026/09/cisa-adds-seven-exploited-flaws-as.html); das KEV-Datum 2. September folgt der Zeitleiste von Wiz. Die Analyseabschnitte werden von der faktischen Berichterstattung getrennt gehalten. Zu beachten ist, dass Instanzzahlen und der Anteil an Cloud-Umgebungen Schätzungen sind, die von Zeitpunkt und Methode der Messung abhängen.