LiteLLM-Lücke macht KI-Gateways zum Einfallstor : CISA warnt vor aktiven Angriffen auf CVE-2026-42271 in LiteLLM

Die U.S. Cybersecurity and Infrastructure Security Agency (CISA) hat die Schwachstelle CVE-2026-42271 in ihren Known Exploited Vulnerabilities (KEV)-Katalog aufgenommen. Damit stuft die Behörde das Risiko nicht mehr nur theoretisch ein: Es gibt Hinweise auf aktive Ausnutzung in realen Umgebungen. Betroffen ist LiteLLM, ein Open-Source-KI-Gateway und Python SDK von BerriAI, das häufig als Vermittlungsschicht zwischen Anwendungen, großen Sprachmodellen und Modellanbietern eingesetzt wird.

CVE-2026-42271 wird mit einem CVSS-Wert von 8.7 eingestuft. Technisch handelt es sich um eine Command-Injection-Schwachstelle. Jeder authentifizierte Nutzer konnte dadurch beliebige Befehle auf dem Host ausführen, sofern die betroffene LiteLLM-Version im Einsatz war.

Betroffen sind folgende Versionen des LiteLLM-Python-Pakets:

• ab Version 1.74.2
• vor Version 1.83.7

Wie aus einem Test-Endpunkt ein Ausführungspfad wurde

Der Kern des Problems liegt in zwei Endpunkten, die eigentlich dazu gedacht waren, einen Model Context Protocol (MCP)-Server vor dem Speichern zu testen: POST /mcp-rest/test/connection und POST /mcp-rest/test/tools/list. Diese Endpunkte akzeptierten laut BerriAI eine vollständige Serverkonfiguration im Request Body – einschließlich der Felder command, args und env, die vom Stdio-Transport genutzt werden.

BerriAI beschreibt den Ablauf so: „Beim Aufruf mit einer Stdio-Konfiguration versuchten die Endpunkte, eine Verbindung herzustellen. Dadurch wurde der übergebene Befehl als Subprozess auf dem Proxy-Host mit den Rechten des Proxy-Prozesses gestartet.“ Genau diese Logik machte aus einer Vorschaufunktion einen direkten Pfad zur Befehlsausführung.

Erschwerend kommt hinzu, dass die Endpunkte lediglich durch einen gültigen Proxy API-Schlüssel geschützt waren. Damit konnten auch interne Nutzer mit entsprechenden Schlüsseln Befehle auf verwundbaren Systemen ausführen. Mit Version 1.83.7 hat BerriAI die Berechtigungsprüfung verschärft: Beide Test-Endpunkte erfordern nun die Rolle PROXY_ADMIN und verhalten sich damit konsistent zum Speichern-Endpunkt.

Verkettung mit Starlette hebelt die Hürde aus

Besonders kritisch wird CVE-2026-42271 durch eine von Horizon3.ai beschriebene Angriffskette. Demnach lässt sich die Lücke mit CVE-2026-48710 kombinieren, einer sogenannten BadHost-Schwachstelle in der Host-Header-Validierung von Starlette. Starlette ist ein leichtgewichtiges Asynchronous Server Gateway Interface (ASGI)-Framework und kann in der Abhängigkeitskette betroffener LiteLLM-Installationen enthalten sein.

Horizon3.ai erklärt, warum die Lücke in der Praxis besonders gefährlich werden kann: CVE-2026-42271 setzt eigentlich voraus, dass ein Angreifer bereits über einen gültigen API-Schlüssel verfügt. In Kombination mit CVE-2026-48710 kann diese Hürde jedoch entfallen. Die Schwachstelle in Starlette erlaubt es unter bestimmten Bedingungen, die Authentifizierung in betroffenen LiteLLM-Installationen zu umgehen. Das gilt für Deployments, deren Abhängigkeiten Starlette bis einschließlich Version 1.0.0 enthalten. Aus einer Schwachstelle, die zunächst nur für angemeldete Nutzer ausnutzbar ist, kann so eine unauthentifizierte Remote Code Execution werden: Angreifer benötigen dann keine Zugangsdaten mehr, um Befehle auf dem System auszuführen.

Nach Angaben von Horizon3.ai erreicht diese Angriffskette einen kombinierten CVSS-Wert von 10.0 und ist damit höchst kritisch. Der mögliche Schaden geht weit über den kompromittierten LiteLLM-Host hinaus. Angreifer könnten dort nicht nur beliebige Befehle ausführen, sondern auch Zugangsdaten zu Modellanbietern, API-Schlüssel und andere im Proxy gespeicherte Geheimnisse auslesen. Von dort aus könnten sie sich weiter in angebundene KI-Infrastrukturen bewegen und Systeme kompromittieren, die über das Gateway mit LiteLLM verbunden sind.

Unklare Angriffslage, hohes Schadenspotenzial

Bislang ist nicht öffentlich bekannt, wie CVE-2026-42271 konkret ausgenutzt wird. Auch zu den Angreifern, Zielbranchen, der Verbreitung der Angriffe und möglichen erfolgreichen Kompromittierungen liegen aktuell keine gesicherten Informationen vor. Ebenso bleibt offen, ob die beobachteten Angriffe bereits die vollständige Angriffskette mit Starlette nutzen oder sich auf die authentifizierte Command Injection beschränken.

Für Betreiber ist diese Unsicherheit jedoch kein Grund zur Entwarnung. LiteLLM sitzt häufig an einer sicherheitskritischen Stelle: zwischen Anwendungen, Modellen, Zugangsschlüsseln, internen Diensten und externen Modellanbietern. Eine Kompromittierung des Gateways kann daher schnell zu einem Kontrollverlust über mehrere Ebenen der KI-Architektur führen.

Updates und Sofortmaßnahmen

Nutzer sollten LiteLLM auf Version 1.83.7 oder neuer aktualisieren. Zusätzlich sollte Starlette mindestens auf Version 1.0.1 gebracht werden, sofern es in der Abhängigkeitskette betroffener Deployments enthalten ist. Ist ein sofortiges Update nicht möglich, werden folgende Maßnahmen empfohlen:

• POST /mcp-rest/test/connection und POST /mcp-rest/test/tools/list am Reverse Proxy oder API Gateway blockieren
• Netzwerkzugriff auf vertrauenswürdige Segmente beschränken
• Vom Proxy gespeicherte Zugangsdaten rotieren
• Protokolle auf ungewöhnliche Host-Header-Aktivitäten und Subprozess-Ausführungen prüfen

Die neue Warnung reiht sich in eine Serie schwerer Sicherheitsprobleme rund um LiteLLM ein. Erst etwas mehr als einen Monat zuvor war eine kritische SQL-Injection-Schwachstelle in LiteLLM unter der Kennung CVE-2026-42208 bekannt geworden. Sie erreichte einen CVSS-Wert von 9.3 und wurde innerhalb von 36 Stunden nach Bekanntwerden aktiv ausgenutzt.

Wer bei KI-Gateways nur auf klassische Anwendungssicherheit setzt, übersieht die besondere Rolle dieser Komponenten: Ein KI-Proxy ist nicht bloß ein weiteres System im Netz, sondern häufig ein privilegierter Knotenpunkt zwischen Daten, Modellen und Geschäftsprozessen.