zeltoc/threat-intel-brief-cve-2026-42208-litellm# Threat-Intelligence-Brief zu CVE-2026-42208, einer kritischen Pre-Auth-SQL-Injection in BerriAI LiteLLM, die innerhalb von 36 Stunden nach Offenlegung ausgenutzt wurde. Behandelt Angriffspfad, Erkennungsmöglichkeiten und empfohlene Maßnahmen.
CVE: CVE-2026-42208
GHSA: GHSA-r75f-5x8p-qvmc
CVSS-Score: 9.3 (Kritisch)
Betroffene Software: BerriAI LiteLLM Versionen >= 1.81.16, < 1.83.7
Behobene Version: 1.83.7-stable (veröffentlicht am 19. April 2026)
CISA KEV hinzugefügt: 08. Mai 2026
Quellen: CISA KEV, Sysdig TRT, The Hacker News, Security Affairs
Eine kritische SQL-Injection-Schwachstelle ohne Authentifizierung im Python-Paket LiteLLM von BerriAI wurde innerhalb von 36 Stunden nach der öffentlichen Offenlegung aktiv in freier Wildbahn ausgenutzt. LiteLLM ist ein Open-Source-KI-Gateway mit über 22.000 GitHub-Sternen, das von Organisationen häufig zur Verwaltung von API-Aufrufen über mehrere LLM-Anbieter hinweg eingesetzt wird, darunter OpenAI, Anthropic und cloud-gehostete Modelle. Eine erfolgreiche Ausnutzung verschafft einem nicht authentifizierten Angreifer Lese- und Schreibzugriff auf die Proxy-Datenbank, in der LLM-Anbieter-API-Schlüssel, Cloud-Anmeldedaten, virtuelle Schlüssel und Budgetkonfigurationen für Ausgaben gespeichert sind. CISA hat diese Schwachstelle am 08. Mai 2026 in den Katalog der Bekannten Ausgenutzten Schwachstellen (KEV) aufgenommen.
LiteLLM ist ein Proxy-Server, der eine OpenAI-kompatible REST-API als einheitliches Frontend für Dutzende von Upstream-LLM-Anbietern bereitstellt. Organisationen nutzen ihn, um die LLM-Zugriffskontrolle zu zentralisieren, Ratenbegrenzungen anzuwenden, Ausgaben zu verfolgen und Anmeldedaten über mehrere Modellanbieter hinweg von einem einzigen Punkt aus zu verwalten. Der Proxy speichert API-Schlüssel und Cloud-Anbieter-Anmeldedaten in einer PostgreSQL-Backend-Datenbank.
Die zentralisierte Speicherung von Anmeldedaten macht diese Schwachstelle besonders folgenschwer. Eine kompromittierte LiteLLM-Instanz legt nicht nur einen einzelnen API-Schlüssel offen – sie legt potenziell jede Cloud-Anmeldedaten offen, die die Organisation über alle LLM-Anbieter hinweg konfiguriert hat.
Der Fehler liegt im Proxy-API-Schlüssel-Verifizierungsprozess von LiteLLM. Wenn eine Anfrage eintrifft, prüft der Proxy den Wert des Authorization: Bearer-Headers gegen seine Datenbank, um den Aufrufer zu authentifizieren. In betroffenen Versionen wurde der Bearer-Token-Wert direkt in die SQL-Abfragezeichenfolge eingefügt, anstatt als parametrisierte Eingabe übergeben zu werden:
# Verwundbares Muster (vor v1.83.7)
cursor.execute(f"SELECT * FROM LiteLLM_VerificationToken WHERE key = '{api_key}'")
Ein einzelnes Anführungszeichen im Bearer-Wert ermöglicht es einem Angreifer, das String-Literal zu verlassen und beliebige SQL-Anweisungen anzuhängen. Da der Injektionspunkt in der Authentifizierungsprüfung selbst liegt, sind keine gültigen Anmeldedaten erforderlich, um sie auszulösen.
POST /chat/completions)Authorization: Bearer-Header enthält eine SQL-Injection-PayloadDas Threat Research Team von Sysdig beobachtete reale Exploit-Versuche, die auf Folgendes abzielten:
LiteLLM_VerificationToken – virtuelle API-Schlüssel und Zugriffskontrollen| Datum/Uhrzeit | Ereignis |
|---|---|
| 19. April 2026 | Patch veröffentlicht (LiteLLM v1.83.7-stable) |
| 20. April 2026, 21:14 UTC | Sicherheitshinweis im Repository der Maintainer veröffentlicht |
| 24. April 2026, 16:17 UTC | Sicherheitshinweis in der globalen GitHub-Sicherheitsdatenbank indexiert (Defender-Feeds erscheinen hier) |
| 26. April 2026, 16:24 UTC | Erster Ausnutzungsversuch von Sysdig TRT beobachtet – 36 Stunden 7 Minuten nach der Indexierung |
| 08. Mai 2026 | CISA fügt CVE-2026-42208 zum KEV-Katalog hinzu |
Das 36-Stunden-Ausnutzungsfenster ist konsistent mit einem organisierten Bedrohungsakteur, der automatisierte Scans einsetzt, um neue CVE-Veröffentlichungen zu überwachen und schnell Exploit-Code zu entwickeln oder anzupassen. SQL-Injection ist eine gut verstandene Schwachstellenklasse – sobald der betroffene Codepfad identifiziert ist, ist die Waffenisierung unkompliziert.
Vertraulichkeit: Hoch – Datenbankinhalte lesbar, einschließlich Anmeldedaten
Integrität: Hoch – Datenbank beschreibbar, Schlüssel können hinzugefügt, geändert oder gelöscht werden
Verfügbarkeit: Mittel – Proxy kann durch Datenbankänderungen gestört werden
Erforderliche Authentifizierung: Keine – vollständig ohne Authentifizierung
Erforderlicher Netzwerkzugriff: Ja – der Angreifer muss den Proxy-Port erreichen können
Warum dies über eine typische SQLi hinausgeht: LiteLLM ist speziell darauf ausgelegt, die Anmeldedatenverwaltung zu zentralisieren. Eine Organisation, die eine kompromittierte LiteLLM-Instanz betreibt, hat möglicherweise API-Schlüssel für OpenAI, Anthropic, Azure OpenAI, AWS Bedrock und andere Anbieter konfiguriert. Jeder dieser Schlüssel repräsentiert Zugriff auf kostenpflichtige LLM-Dienste mit potenziell erheblichen Ausgabenlimits. Über den Missbrauch von LLM-Ausgaben hinaus könnten Cloud-Anbieter-Anmeldedaten in der Datenbank eine seitliche Bewegung in AWS-, Azure- oder GCP-Umgebungen ermöglichen.
| Status | Versionen |
|---|---|
| Verwundbar | >= 1.81.16 und < 1.83.7 |
| Gepatcht | >= 1.83.7-stable |
Achten Sie auf HTTP-Anfragen an LiteLLM-Endpunkte, die SQL-Metazeichen im Authorization-Header enthalten:
Authorization: Bearer ' OR 1=1--
Authorization: Bearer '; SELECT * FROM LiteLLM_VerificationToken--
Authorization: Bearer ' UNION SELECT--
Indikatoren, nach denen in Proxy-Logs gesucht werden sollte:
/chat/completions, /embeddings oder andere API-Routen mit fehlerhaften Bearer-TokensLiteLLM_VerificationToken mit ungewöhnlichen WHERE-Klauseln| Technik | ID | Beschreibung |
|---|---|---|
| Ausnutzung öffentlich zugänglicher Anwendungen | T1190 | SQL-Injection gegen internetzugänglichen LiteLLM-Proxy |
| Anmeldedaten aus Passwortspeichern | T1555 | Extraktion von API-Schlüsseln und Cloud-Anmeldedaten aus der Proxy-Datenbank |
| Gültige Konten: Cloud-Konten | T1078.004 | Verwendung gestohlener Cloud-Anbieter-Anmeldedaten nach der Ausnutzung |
Sofort (falls betroffene Versionen ausgeführt werden):
Kurzfristig: 5. Netzwerkzugriff auf den LiteLLM-Proxy-Port einschränken – er sollte ohne vorgeschaltete Authentifizierung nicht direkt internetzugänglich sein 6. Datenbank-Abfrageprotokollierung aktivieren, um zukünftige Injektionsversuche zu erkennen 7. WAF-Regeln hinzufügen, um Authorization-Header auf SQL-Metazeichen zu prüfen
Fortlaufend: 8. CISA-KEV-Benachrichtigungen abonnieren – diese Schwachstelle wurde aktiv ausgenutzt, bevor die meisten Patch-Zyklen sie erfasst hätten 9. KI-Infrastruktur als hochwertige Anmeldedatenspeicher behandeln – dieselben Sicherheitskontrollen, die auf Secrets-Manager angewendet werden, sollten auch auf LLM-Proxy-Bereitstellungen angewendet werden
Warum KI-Infrastruktur ein wachsendes Ziel ist: LiteLLM und ähnliche Tools befinden sich in einer privilegierten Position – sie halten Anmeldedaten für kostenpflichtige Cloud-Dienste mit hohen Ausgabenlimits und werden oft von Engineering-Teams statt von Sicherheitsteams mit weniger ausgereifter Sicherheitsprüfung bereitgestellt. Das Sysdig-Team stellte ausdrücklich fest, dass LiteLLM-Betreiber „ihm vertrauen, um Cloud-Anmeldedaten auf Unternehmensebene zu zentralisieren", was es zu einem attraktiven Ziel für Anmeldedatendiebstahl und Missbrauch von LLM-Diensten macht (Verwendung gestohlener API-Schlüssel, um eigene Abfragen gegen kostenpflichtige Modelle auszuführen).
Das 36-Stunden-Ausnutzungsfenster ist ein Maßstab: Dies ist keine Anomalie. Bedrohungsakteure überwachen aktiv CVE-Veröffentlichungsfeeds und Sicherheitsdatenbanken. Bei kritischen Schwachstellen ohne Authentifizierung in weit verbreiteter Open-Source-Software ist davon auszugehen, dass die Ausnutzung innerhalb von 24–48 Stunden nach der öffentlichen Offenlegung beginnt. Patch-SLAs müssen dieser Realität Rechnung tragen – ein 30-Tage-Patch-Fenster ist für CVSS-9+-Schwachstellen ohne Authentifizierung nicht angemessen.
CISA KEV als Priorisierungssignal: Der KEV-Katalog enthält nur Schwachstellen mit bestätigter realer Ausnutzung. Wenn eine CVE im KEV erscheint, ist sie nicht theoretisch – jemand hat sie bereits gegen reale Ziele eingesetzt. Organisationen sollten KEV-Einträge unabhängig von ihren internen CVSS-basierten Priorisierungsschwellen als sofortige Maßnahmen behandeln.