LiteLLM-MCP-Command-Injection: CVE-2026-42271

GTIG bestätigt die Ausnutzung von CVE-2026-42271: Gültige LiteLLM-Schlüssel starteten Befehle über MCP-Vorschauen. Update auf 1.83.7+.^{[1], [6], [8]}

CVSS-Vektor

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:N/SA:N^[1]

💡 Einfache Erklärung (ELI5)

Eine Werkstatt lässt Besucher ein Werkzeug vor dem Hinzufügen ausprobieren. Der Prüfstand kann eine leistungsfähige Werkstattmaschine starten; nur eine Aufsichtsperson sollte ihr Anweisungen geben dürfen. In anfälligen LiteLLM-Versionen erreichte jede akzeptierte Karte diesen Prüfstand. Eine separate Starlette-Schwachstelle konnte außerdem eine Zugangskontrolle täuschen, die anhand einer rekonstruierten URL entscheidet. Beide Grenzen brauchen eine eigene Korrektur. An einem zweiten Schalter kann ein Besucher einen Schrägstrich oder ein Fragezeichen auf das Paketetikett schreiben. Beim Zusammensetzen der Adresse übernimmt der Sachbearbeiter diesen Text und hält ihn für einen neuen Weg, obwohl das Paket weiterhin durch den ursprünglichen Flur läuft. Das veranschaulicht die separate Host-Pfad-Verwechslung in Starlette.^{[1], [3], [5]}

Kernkonzepte & Begriffe

Model Context Protocol (MCP): Ein Protokoll, über das sich eine Anwendung wie ein KI-Gateway mit externen Werkzeugen und Datenquellen verbindet. LiteLLM-Vorschau-Endpunkte testen eine MCP-Konfiguration vor dem Speichern.^[1]
stdio-Transport: Ein MCP-Verbindungsmodus, der einen lokalen Kindprozess startet und Nachrichten über Standardeingabe und -ausgabe austauscht. Der Prozess läuft auf dem LiteLLM-Proxy-Host mit den Betriebssystemrechten des Proxy-Dienstes.^{[1], [2]}
Rollenbasierte Autorisierung: Eine serverseitige Prüfung, die einen Vorgang nur Identitäten mit der erforderlichen Rolle erlaubt. Bei CVE-2026-42271 fehlte den Vorschau-Routen die PROXY_ADMIN-Prüfung, die beim Speichern verwendet wurde.^{[1], [2]}
CVE-2026-48710 (Starlette BadHost): Eine separate Starlette-Schwachstelle: Ein ungültiger Host-Header konnte bewirken, dass request.url.path vom tatsächlich gerouteten Pfad abwich. Horizon3 berichtete, dass dies bei bestimmten Abhängigkeiten die pfadbasierte LiteLLM-Authentifizierung umgehen kann; es ist nicht Teil von CVE-2026-42271.^{[3], [5], [4]}
Zulassungsliste für MCP-stdio-Befehle: Menge von ausführbaren Basisnamen, die LiteLLM für den stdio-Transport akzeptiert. Die Prüfung erfolgt bei der Konfigurationsvalidierung und vor dem Erstellen des Clients erneut für ältere Einträge. Sie ist keine Sandbox, da erlaubte Laufzeitumgebungen übergebene Argumente interpretieren können.^[8]

Framework-Zuordnungen

CWE-Referenz für die in diesem Leitfaden beschriebene Schwachstelle: CWE-78
CISA KEV — aufgenommen am 2026-06-08 — CVE-2026-42271

Schritt-für-Schritt Angriffsablauf

Schritt 1

LiteLLM-Version und erreichbare Endpunkte prüfen

Laut Maintainer-Advisory sind LiteLLM-Versionen >=1.74.2 und <1.83.7 betroffen; erforderlich ist ein gültiger Proxy-API-Schlüssel. Vor dem Fix konnte jeder authentifizierte Schlüsselinhaber, auch mit einem Schlüssel für interne Benutzer mit geringen Rechten, die Vorschau-Routen nutzen. GTIG führt CVE-2026-42271 in seiner Liste bestätigter Ausnutzung auf; für die Voraussetzungen dieses CVE gilt das authentifizierte Bedrohungsmodell des Maintainer-Advisorys.^{[1], [6]}

Schritt 2

Ein Schlüssel mit geringeren Rechten erreicht eine administrative Vorschauaktion

Die Endpunkte akzeptierten eine vollständige MCP-Serverkonfiguration einschließlich stdio-Befehl, Argumenten und Umgebungsvariablen. Der Server authentifizierte den Schlüssel, prüfte aber nicht die Rolle PROXY_ADMIN. Daher konnte jede authentifizierte Person die Vorschau aufrufen.^[1]

Schritt 3

Die Vorschau startet einen Prozess auf dem Proxy-Host

Zum Testen der übermittelten stdio-Konfiguration erstellte LiteLLM einen MCP-Client und startete den konfigurierten Kindprozess mit den Rechten des Proxy-Dienstes. Das ist Befehlsausführung auf dem Gateway-Host und nicht lediglich unsicherer Modelltext.^{[2], [8]}

Schritt 4

Eine separate Starlette-Schwachstelle kann die Authentifizierungsgrenze schwächen

Horizon3 berichtete, dass CVE-2026-48710 bei einer betroffenen Starlette-Version dazu führen kann, dass eine pfadbasierte Authentifizierung ein anderes request.url.path sieht als die von Starlette ausgewählte Route. Die Forschenden meldeten, dieses Verhalten mit CVE-2026-42271 verkettet und damit die API-Schlüssel-Anforderung in betroffenen Deployments aufgehoben zu haben. Diese Kette Horizon3 zuschreiben; die CVEs haben getrennte Ursachen und Patches.^{[5], [3], [4]}

Schritt 5

Beide Grenzen patchen und aufgelöste Pakete kontrollieren

LiteLLM korrigierte die Vorschau-Routen in Version 1.83.7: Sie erfordern nun PROXY_ADMIN, und tools/list besitzt eine explizite Authentifizierung. Der Patch prüft die Zulassungsliste außerdem bei neuen/aktualisierten Anfragen und erneut in _create_mcp_client, um ältere Konfigurationen abzufangen. Die Liste ist keine Sandbox; erlaubte Laufzeitumgebungen interpretieren weiterhin Argumente. Starlette behob CVE-2026-48710 separat in Version 1.0.1. Prüfen Sie die tatsächlich aufgelösten Paketversionen und bewerten Sie die gemeldete Kette unabhängig.^{[1], [8], [4], [7]}

Schritt 6

Aktueller Kampagnenkontext (gemeldet am 7. Oktober 2026)

Black Lotus Labs berichtete, dass ein PoeLLM-Malware-Sample wahrscheinlich /mcp-rest/test/connection anvisierte; BleepingComputer meldete ebenfalls Versuche, CVE-2026-42271 in der Kampagne auszunutzen. Der Bericht belegt weder, dass alle infizierten Hosts über dieses CVE kompromittiert wurden, noch dass jedes LiteLLM-Ziel verwundbar war. Dies ist ein Hinweis auf aktuelle Zielauswahl, keine diesem Fehler zurechenbare Opferzahl.^{[9], [10]}

Ursachenanalyse

Der LiteLLM-Fehler bestand darin, dass auf beiden MCP-Vorschau-Endpunkten eine Rollenprüfung fehlte: Jeder gültige Proxy-API-Schlüssel konnte sie ohne die Rolle PROXY_ADMIN aufrufen. Die Verbindungsvorschau akzeptierte eine vom Client gelieferte stdio-Konfiguration und startete den Befehl mit den Rechten des Proxy-Prozesses. Ein separater Starlette-Fehler ermöglichte es einem fehlerhaften Host-Header, request.url.path vom tatsächlich gerouteten Pfad abweichen zu lassen; Horizon3 berichtete, dass sich eine pfadbasierte API-Schlüsselprüfung in einer Kette mit LiteLLM umgehen ließ. Es handelt sich um getrennte Schwachstellen: Beheben Sie die Autorisierungs- und Befehlsausführungsgrenzen in LiteLLM und aktualisieren Sie Starlette auf Version 1.0.1 oder höher.^{[1], [8], [3], [4], [5]}

Quellcode: Verwundbar vs. Sicher

Dieser Ausschnitt zeigt den zusammengeführten LiteLLM-Fix an der Ausführungsgrenze: Vor dem Erstellen des stdio-Clients wird der Basisname des Befehls geprüft, sodass auch ältere Datenbank-/Konfigurationseinträge die Prüfung durchlaufen. Der Patch validiert außerdem neue und aktualisierte Serverkonfigurationen und beschränkt beide Vorschau-Endpunkte auf PROXY_ADMIN; /test/tools/list erhielt zusätzlich die explizite Abhängigkeit user_api_key_auth. Die Zulassungsliste ist keine Sandbox: Erlaubte Laufzeitumgebungen können ihre Argumente weiterhin interpretieren. Beschränken Sie Vorschauen auf Administratoren und betreiben Sie den Proxy mit minimalen Rechten.^{[1], [2], [8]}

Quelltextauszug: Prüfausschnitt des LiteLLM-stdio-Clients

VERWUNDBARE IMPLEMENTIERUNG

# _create_mcp_client vor dem Schutz vor stdio-Befehlen.
if server.command and server.args is not None:
    stdio_config = MCPStdioConfig(
        command=server.command,
        args=server.args,
        env=resolved_env,
    )

GEHÄRTETER SICHERHEITS-PATCH

# _create_mcp_client: ältere Datenbank-/Konfigurationseinträge erneut prüfen.
if server.command:
    base_command = os.path.basename(server.command)
    if base_command not in MCP_STDIO_ALLOWED_COMMANDS:
        raise HTTPException(
            status_code=403,
            detail="MCP stdio command is not in the allowlist",
        )

if server.command and server.args is not None:
    stdio_config = MCPStdioConfig(
        command=server.command,
        args=server.args,
        env=resolved_env,
    )

Checkliste für Engineering & Systemsicherheit

✓Inventarisieren Sie LiteLLM-Proxy-Deployments und prüfen Sie die tatsächlich aufgelöste Version; aktualisieren Sie betroffene Releases auf 1.83.7 oder neuer.^{[1], [8]}
✓Prüfen Sie Lockfile oder Container-Image und bestätigen Sie Starlette 1.0.1 oder neuer, sofern die aufgelöste FastAPI-Version dies zulässt; erzwingen Sie kein ungeprüftes Dependency-Override.^{[3], [7]}
✓Sperren Sie bis zum LiteLLM-Upgrade POST /mcp-rest/test/connection und POST /mcp-rest/test/tools/list am Reverse-Proxy oder API-Gateway, wie im Maintainer-Advisory empfohlen.^[1]
✓Prüfen Sie, dass beide Routen user_api_key_auth verlangen und jede andere Rolle als PROXY_ADMIN vor dem Erstellen eines MCP-Clients abweisen.^{[1], [8]}
✓Ergänzen Sie Tests, die belegen, dass anonyme Anfragen und gültige Nicht-Admin-Schlüssel keine Vorschau auslösen können, während autorisierte Admins den vorgesehenen Ablauf nutzen können.^[8]
✓Testen Sie für Starlette den Umgang mit fehlerhaften Host-Headern und stellen Sie sicher, dass Zugriffsmiddleware den kanonischen ASGI-Pfad oder eine vom Framework validierte URL verwendet.^{[3], [4]}
✓Untersuchen Sie Proxy-Logs und Prozess-Telemetrie auf unerwartete Nutzung der MCP-Vorschau-Routen; erneuern Sie Proxy-Zugangsdaten, falls die Untersuchung plausiblen Host-Zugriff ergibt.^{[1], [8]}
✓Führen Sie getrennte Schwachstellenakten: CVE-2026-42271 betrifft LiteLLM-Befehlsausführung; CVE-2026-48710 betrifft Starlette-Host-Parsing und Pfadverwechslung.^{[1], [3]}
✓Prüfen Sie LITELLM_MCP_STDIO_EXTRA_COMMANDS in jeder Umgebung; benutzerdefinierte Einträge erweitern die Vertrauensgrenze für ausführbare Dateien und machen die Argumentverarbeitung nicht sicher.^[8]

Quellen

← AI Security Directory →