LiteLLM CVE-2026-42271: MCP-Test-Endpunkte plus BadHost ergeben unauthentifizierte RCE (CVSS 10.0) — nachträglich aufgegriffen

TL;DR — 90 Sekunden

Betroffen?

LiteLLM ≥1.74.2 und <1.83.7, insbesondere in Kombination mit Starlette vor 1.0.1 (BadHost, CVE-2026-48710). Die beiden Endpunkte POST /mcp-rest/test/connection und POST /mcp-rest/test/tools/list sind der Angriffspfad.

Risiko?

Command Injection (CVSS 8.7 einzeln) → verkettet mit BadHost zu unauthentifizierter RCE (CVSS 10.0 kombiniert). Aktiv ausgenutzt laut CISA-KEV-Eintrag.

Sofortmaßnahme?

LiteLLM auf ≥1.83.7 UND Starlette auf ≥1.0.1 aktualisieren — nur eine der beiden Komponenten zu patchen schliesst die Kette nicht vollständig.

Empfehlung?

Wer den bereits behandelten BadHost-Fund (CVE-2026-48710) gepatcht hat, aber LiteLLM nicht separat aktualisiert hat, bleibt über die MCP-Test-Endpunkte angreifbar — beide Advisories gehören zusammen geprüft.

Kritikalität?

kritisch (Hero-Badge) — kombinierte unauthentifizierte RCE, CISA-KEV-Eintrag, aktive Ausnutzung.

Was ist das Problem?

LiteLLM ist ein weit verbreitetes AI-Gateway/Proxy, das einheitlichen Zugriff auf verschiedene LLM-Provider bündelt und dabei auch das Model Context Protocol (MCP) unterstützt. Zwei Vorschau-Endpunkte, POST /mcp-rest/test/connection und POST /mcp-rest/test/tools/list, nehmen eine vollständige Server-Konfiguration im Request-Body entgegen — inklusive command-, args- und env-Feldern. Diese Felder werden unzureichend validiert, wodurch authentifizierte Nutzer beliebige Kommandos auf dem Host ausführen können.

Für sich genommen erfordert das einen authentifizierten Zugang. Die eigentliche Brisanz entsteht durch die Verkettung mit CVE-2026-48710 (BadHost): Starlette vor Version 1.0.1 rekonstruiert request.url fehlerhaft aus dem Host-Header, was unter bestimmten Bedingungen die Authentifizierung selbst aushebeln kann. Kombiniert ergibt sich ein Pfad zu vollständig unauthentifizierter Remote Code Execution — daher die kombinierte CVSS-Bewertung von 10.0.

Wer ist betroffen?

Beide Komponenten müssen aktualisiert werden, um die Kette vollständig zu schliessen: LiteLLM allein schliesst nur die Command-Injection-Endpunkte, Starlette allein schliesst nur den Host-Header-Bypass. Wer bereits den separat behandelten BadHost-Fund (Starlette-Seite) gepatcht, aber LiteLLM nicht auf ≥1.83.7 gezogen hat, bleibt über die MCP-Test-Endpunkte für authentifizierte Angreifer verwundbar.

Auswirkungen

Der kombinierte Pfad — unauthentifizierte Remote Code Execution auf einem AI-Gateway — ist maximal kritisch: LiteLLM-Instanzen bündeln typischerweise API-Keys für mehrere LLM-Provider, Routing-Konfigurationen und häufig auch Zugriff auf nachgelagerte interne Systeme. Ein erfolgreicher Angriff bedeutet vollständige Kompromittierung des Gateway-Hosts, Zugriff auf alle verwalteten Provider-Keys und potenziell einen Sprungpunkt ins interne Netzwerk. Selbst ohne die Verkettung mit BadHost bleibt die Command Injection für authentifizierte Nutzer ein ernstes Risiko in Umgebungen mit mehreren Nutzern unterschiedlicher Vertrauensstufen.

Mitigation / Sofortmassnahmen

Hinweis: Basierend auf der zitierten Berichterstattung und dem CISA-KEV-Eintrag — konkrete Versionsstände gegen die offiziellen LiteLLM- und Starlette-Release-Notes abgleichen.

Operativer Entscheidungsblock

• Jetzt handeln, wenn … Sie LiteLLM in einer Version zwischen 1.74.2 und <1.83.7 betreiben — unabhängig vom Starlette-Patch-Status.
• Mit Priorität prüfen, wenn … Sie den BadHost-Fund bereits behandelt haben, aber nicht sicher sind, ob LiteLLM separat aktualisiert wurde.
• Nur beobachten, wenn … Sie bereits auf LiteLLM ≥1.83.7 mit Starlette ≥1.0.1 sind.

Schritt 1 — beide Komponenten aktualisieren

# LiteLLM-Version prüfen
pip show litellm | grep Version
# auf sichere Version aktualisieren
pip install --upgrade litellm>=1.83.7
# Starlette-Version separat prüfen und aktualisieren
pip show starlette | grep Version
pip install --upgrade starlette>=1.0.1

Schritt 2 — MCP-Test-Endpunkte am Reverse Proxy blocken (bis zum Patch)

# Beispiel nginx: die beiden Vorschau-Endpunkte sperren
location ~ ^/mcp-rest/test/(connection|tools/list) {
    deny all;
}

Schritt 3 — Netzwerkzugriff einschränken

# LiteLLM-Gateway nicht direkt öffentlich exponieren
# Zugriff auf bekannte, vertrauenswürdige Quell-IPs beschränken (Firewall/Security-Group)

Schritt 4 — Proxy-Credentials rotieren

# nach Verdacht auf Kompromittierung:
# alle über LiteLLM verwalteten Provider-API-Keys rotieren
# LiteLLM-eigene Master-/Proxy-Keys neu generieren

Detection / Prüfung

Version prüfen

pip show litellm starlette | grep -E "Name|Version"

Logs auf Zugriffe der Test-Endpunkte prüfen

grep -E "POST /mcp-rest/test/(connection|tools/list)" access.log | awk '{print $1, $7}' | sort -u

Auf Host-Header-Anomalien prüfen (BadHost-Seite)

grep -i "^Host:" access.log | sort | uniq -c | sort -rn | head -20

Laufzeit-Indikatoren

- unerwartete Subprozess-Ausführungen vom LiteLLM-Prozess ausgehend
- ausgehende Verbindungen von der LiteLLM-Instanz zu unbekannten Zielen
- Requests an die MCP-Test-Endpunkte von Quellen ausserhalb bekannter Nutzer/Systeme

Betreiberempfehlung

Mid-Market

Beide Komponenten (LiteLLM und Starlette) in einem Schritt aktualisieren — ein Teil-Patch schliesst die Kette nicht. Falls Sie den BadHost-Beitrag bereits umgesetzt haben, jetzt gezielt LiteLLM separat prüfen.

Enterprise

Dependency-Scan über alle Services, die Starlette oder LiteLLM einsetzen — beide sind häufig transitive Abhängigkeiten in grösseren Python-/ASGI-Stacks und werden leicht übersehen. Netzwerksegmentierung für AI-Gateways wie LiteLLM: kein direkter öffentlicher Zugriff, sondern hinter Auth-Proxy und Allowlist.

KI-Plattform-Betrieb

LiteLLM als zentrales Gateway bündelt Provider-Keys für den gesamten Stack — ein Kompromiss hier hat überproportionale Auswirkung. Master-/Proxy-Keys regelmässig rotieren, unabhängig vom aktuellen Patch-Status, als generelle Hygienemassnahme.

Entscheidungsblock

Heute handeln, wenn: LiteLLM <1.83.7 unabhängig vom Starlette-Status. Beobachten, wenn: beide Komponenten bereits auf sicherer Version.

Fazit

CVE-2026-42271 ist ein Lehrbeispiel dafür, warum Einzel-CVE-Betrachtung zu kurz greifen kann: für sich genommen eine Command Injection mit Authentifizierungs-Voraussetzung, in Kombination mit einem bereits bekannten Framework-Bug aber vollständig unauthentifizierte RCE. Wer den BadHost-Beitrag bereits umgesetzt hat, sollte jetzt gezielt prüfen, ob LiteLLM selbst auf der sicheren Version steht — die Kette ist nur geschlossen, wenn beide Glieder gepatcht sind.

Quellen

• The Hacker News — LiteLLM Flaw CVE-2026-42271 Exploited in the Wild, Chains to Unauthenticated RCE (Juni 2026)
• Horizon3.ai — CVE-2026-42271: LiteLLM Unauthenticated RCE (verkettet mit CVE-2026-48710)
• CISA — CISA Adds Two Known Exploited Vulnerabilities to Catalog (08.06.2026)