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 |