CVE-2026-42208
BerriAI LiteLLM SQL Injection Vulnerability
Beschreibung
CVE-2026-42208 ist eine CRITICAL SQL-Injection-Schwachstelle in BerriAI LiteLLM, einem AI-Gateway-Proxy, der LLM-Anbieter im OpenAI-kompatiblen Format vermittelt, mit einem CVSS-3.1-Score von 9.8. Die Schwachstelle steckt in der Datenbankabfrage zur API-Key-Validierung: von Version 1.81.16 bis 1.83.6 wird der vom Aufrufer gelieferte API-Key in den SQL-String interpoliert, statt als separater Query-Parameter übergeben zu werden. Ein unauthentifizierter Angreifer kann einen präparierten Authorization-Header an jeden LLM-API-Endpunkt wie POST /chat/completions schicken, über den Fehlerbehandlungs-Pfad in die verwundbare Query laufen und Daten in der Proxy-Datenbank lesen oder verändern, einschließlich der Credentials, die LiteLLM für nachgelagerte LLM-Anbieter vorhält. CISA hat CVE-2026-42208 am 8. Mai 2026 in den KEV-Katalog aufgenommen, mit einer Patch-Frist 11. Mai 2026. Der EPSS-Score von 0.374 (97,2. Perzentil) signalisiert sehr hohen aktiven Ausnutzungsdruck. Der Patch ist in LiteLLM 1.83.7 enthalten.
KEV-Informationen
CVSS-Score
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HIm Rechner öffnenBetroffene Produkte
| Hersteller | Produkt | Version |
|---|---|---|
| litellm | litellm | >= 1.81.16, < 1.83.7 |
Mehrere CVSS-Bewertungen
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Referenzen
- https://github.com/BerriAI/litellm/releases/tag/v1.83.7-stable(Product, Release Notes)
- https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc(Mitigation, Patch, Vendor Advisory)
- https://access.redhat.com/security/cve/CVE-2026-42208(Third Party Advisory)
- https://bugzilla.redhat.com/show_bug.cgi?id=2463965(Mitigation, Third Party Advisory)
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-42208.json(Third Party Advisory)
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-42208(US Government Resource)
Schwachstellentyp
CWE-89: Unzureichende Neutralisierung von SQL-Sonderzeichen (SQL-Injection)
CWE-89 beschreibt den klassischen Fehlermodus, bei dem ungeprüfte Eingaben ohne Trennung zwischen Code und Daten in eine SQL-Anweisung gemischt werden. In CVE-2026-42208 liest der LiteLLM-Proxy den API-Key aus dem eingehenden Authorization-Header und verkettet ihn in den SQL-String zur Key-Validierung, statt ihn als gebundenen Parameter zu übergeben. Ein Angreifer, der den Header-Inhalt kontrolliert, kontrolliert einen Teil der Query-Syntax und kann zusätzliche SQL-Klauseln anhängen, Union-Queries zum Exfiltrieren von Datenbankzeilen einsetzen oder Update-Statements zum Modifizieren gespeicherter Credentials nutzen. Da der verwundbare Code im Authentifizierungspfad sitzt, ist er auf jedem vom Proxy bereitgestellten LLM-API-Endpunkt erreichbar und feuert, bevor irgendeine Zugriffskontrolle greift.
Mehr erfahren: CWE-89 — SQL Injection
Auswirkungsanalyse
CVE-2026-42208 hat einen CVSS-3.1-Score von 9.8 (CRITICAL) mit Vektor AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: netzwerkbasiert, niedrige Komplexität, ohne Privilegien, ohne Benutzerinteraktion, einheitlich High-Wirkung auf Vertraulichkeit, Integrität und Verfügbarkeit. LiteLLM wird in Enterprise-Umgebungen häufig als zentrales AI-Gateway deployed, weil es anbieterspezifische Authentifizierung abstrahiert und eine einheitliche Observability-Schicht für OpenAI, Anthropic, Google, Azure, AWS Bedrock und weitere LLM-Anbieter liefert. Die Proxy-Datenbank hält typischerweise die Master-API-Keys jedes angebundenen Anbieters, die intern ausgegebenen virtuellen API-Keys für Teams und Applikationen, Budget- und Quota-Tabellen sowie Request-Logs mit teils sensiblem Prompt-Inhalt. Eine erfolgreiche Ausnutzung verschafft dem Angreifer Lesezugriff auf alle Provider-API-Keys (mit Pivot-Möglichkeit in jeden verbundenen LLM-Account), die Möglichkeit virtuelle Keys auszustellen oder zu modifizieren sowie Schreibzugriff auf Abrechnungs- und Quota-Kontrollen. Wo LiteLLM komplette Requests und Responses loggt, ist auch der historische Prompt-Korpus exponiert, der routinemäßig PII, Quellcode und interne Dokumente enthält.
Exploit-Reifegrad
Öffentliche Exploits: Die Schwachstelle ist im GitHub Security Advisory GHSA-r75f-5x8p-qvmc öffentlich dokumentiert, einschließlich der unauthentifizierten Erreichbarkeit über den Fehlerbehandlungs-Pfad. Der Detaillierungsgrad macht die Entwicklung eines funktionierenden Exploits unkompliziert. Aktive Ausnutzung: CISA hat CVE-2026-42208 am 8. Mai 2026 in den KEV-Katalog aufgenommen, mit Patch-Frist 11. Mai 2026 — ein Drei-Tages-Fenster, das beobachtete Ausnutzung gegen produktive LiteLLM-Deployments widerspiegelt. Ausnutzungswahrscheinlichkeit: Der EPSS-Score von 0.374 (97,2. Perzentil) ordnet die CVE in die obersten 3 Prozent aller CVEs nach prognostizierter Ausnutzungswahrscheinlichkeit ein. Praktisches Risiko: LiteLLM ist häufig im öffentlichen Internet oder auf breiten internen Netzwerken exponiert, um AI-Aufrufe vieler Tenants zu vermitteln. Jede LiteLLM-Instanz mit einer Version im Bereich 1.81.16 bis 1.83.6, die für Angreifer erreichbar ist, sollte als kompromittierungswahrscheinlich gelten, mit Exposition aller nachgelagerter LLM-Provider-Keys.
Behebung
- LiteLLM sofort auf 1.83.7 oder höher aktualisieren. Der Fix ist in LiteLLM v1.83.7-stable enthalten. Bestätigen Sie die laufende Version auf jedem Proxy-Host mit
litellm --versionund prüfen Sie in der LiteLLM-Admin-UI. Bei Container-Deployments pinnen Sie den neuen Image-Tag und rollen Sie neu aus. - Jede vom Proxy gehaltene Credential rotieren. Behandeln Sie alle in LiteLLM gespeicherten LLM-Provider-Keys als kompromittiert: Regenerieren Sie OpenAI-, Anthropic-, Google-, Azure-OpenAI-, AWS-Bedrock- und alle weiteren Provider-Keys, die im Proxy konfiguriert sind. Widerrufen und reissue alle virtuellen API-Keys, die LiteLLM an interne Teams und Applikationen ausgegeben hat, und rotieren Sie das von LiteLLM genutzte Datenbankpasswort.
- Auf Kompromittierung prüfen. Inspizieren Sie die LiteLLM-Datenbank auf unerwartete Zeilen in Key-, Budget- und User-Tabellen, insbesondere Einträge, die seit dem Deployment von 1.81.16 entstanden sind. Sichten Sie Request-Logs nach ungewöhnlichen Authorization-Headern mit SQL-Syntax (Single-Quotes, UNION, SELECT, Kommentar-Sequenzen). Prüfen Sie die Dashboards der nachgelagerten Provider auf unerwartete API-Nutzung, neue Keys oder Abrechnungsänderungen.
- Netzwerk-Exposition einschränken. Beschränken Sie die LiteLLM-Admin- und API-Ports per Firewall oder Service-Mesh-Policy auf bekannte Client-Netzwerke. Wo der Proxy externe Clients bedienen muss, platzieren Sie ihn hinter einem authentifizierenden Reverse-Proxy mit Web-Application-Firewall und aktivierten SQL-Injection-Regeln.
- Langfristige Härtung. Wenden Sie das CWE-89-Mitigationsprinzip an: Jeder Datenbanktreiber im Code muss parametrisierte Queries oder eine äquivalente Prepared-Statement-API nutzen. Ergänzen Sie automatisiertes SAST, das den Build bei string-konkatenierter SQL fehlschlagen lässt, und verlangen Sie Security-Review für jeden Code-Pfad, der Authentifizierung oder Session-State verarbeitet. Abonnieren Sie den LiteLLM GitHub Security Advisories Feed für schnelle Benachrichtigung künftiger Issues in dieser kritischen AI-Infrastruktur-Komponente.
Technische Details
CVE-2026-42208 ist eine CWE-89 SQL-Injection-Schwachstelle in der API-Key-Validierungs-Query von BerriAI LiteLLM, Versionen 1.81.16 bis 1.83.6. Der verwundbare Code-Pfad läuft bei jedem eingehenden Request auf jeden LLM-Proxy-Endpunkt wie /chat/completions, /embeddings oder /completions, weil die Key-Validierung vor dem Routing erfolgt. Beim Eintreffen eines Requests extrahiert der Proxy das Bearer-Token aus dem Authorization-Header und konstruiert eine SQL-Anweisung zur Key-Suche in der angebundenen Datenbank, wobei der Wert direkt in den Query-Text konkateniert wird, statt als gebundener Parameter übergeben zu werden. Der erreichbare Trigger ist der Fehlerbehandlungs-Pfad: Ein malformter oder nicht passender Key führt den Proxy in einen Code-Branch, der die unparametrisierte Query ausführt, sodass ein unauthentifizierter Angreifer ohne gültige Credentials probieren kann. Der CVSS-3.1-Vektor AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H bestätigt unauthentifizierte Erreichbarkeit über das Netzwerk mit voller High-Wirkung auf Vertraulichkeit, Integrität und Verfügbarkeit. Die zugrundeliegende Datenbank kann PostgreSQL oder jedes andere Backend sein, gegen das LiteLLM konfiguriert ist; Exploit-Primitives variieren je nach Backend, aber die Kernfähigkeit (lesen und modifizieren der gesamten LiteLLM-Datenbank) ist konsistent. Der Patch in 1.83.7 ersetzt die String-Konkatenation durch eine parametrisierte Query, die den vom Aufrufer gelieferten Key-Wert als Daten bindet und so die Grenze zwischen SQL-Code und Benutzereingabe wiederherstellt.
Häufig gestellte Fragen
Wird CVE-2026-42208 aktiv ausgenutzt?
Ja. CISA hat CVE-2026-42208 am 8. Mai 2026 mit einer Drei-Tages-Patch-Frist 11. Mai 2026 in den KEV-Katalog aufgenommen, was beobachtete Ausnutzung gegen deployte LiteLLM-Instanzen signalisiert. Der EPSS-Score von 0.374 (97,2. Perzentil) spiegelt sehr hohen anhaltenden Ausnutzungsdruck wider.
Welche LiteLLM-Versionen sind betroffen?
Alle LiteLLM-Releases von 1.81.16 bis ausschließlich 1.83.7 sind verwundbar. Der Fix ist in LiteLLM 1.83.7-stable enthalten. Frühere Versionen vor 1.81.16 sind von diesem konkreten Code-Pfad nicht betroffen.
Wie behebe ich CVE-2026-42208?
Aktualisieren Sie auf LiteLLM 1.83.7 oder höher, rotieren Sie anschließend jeden im Proxy konfigurierten nachgelagerten LLM-Provider-Key (OpenAI, Anthropic, Google, Azure, AWS Bedrock und weitere), regenerieren Sie alle an interne Teams ausgegebenen virtuellen API-Keys, rotieren Sie das LiteLLM-Datenbankpasswort und auditieren Sie Request-Logs sowie nachgelagerte Provider-Nutzung auf Kompromittierungsindikatoren. Beschränken Sie den Proxy als Defense-in-Depth-Maßnahme auf bekannte Client-Netzwerke.
Warum ist CVE-2026-42208 für AI-Deployments besonders kritisch?
LiteLLM ist der zentralisierte Credential-Vault für LLM-Zugriff in vielen Enterprise-AI-Architekturen: Es hält die Master-Keys jedes angebundenen Anbieters und vermittelt Requests vieler Teams. Eine erfolgreiche Ausnutzung verschafft nicht nur Zugriff auf die LiteLLM-Datenbank, sondern indirekte Kontrolle über jeden nachgelagerten LLM-Account, dessen Key im Proxy hinterlegt war. Der Expositionsradius ist die gesamte AI-Oberfläche der Organisation, nicht nur der Proxy-Server.
Hilfe beim Schwachstellenmanagement?
Unsere Sicherheitsexperten helfen Ihnen bei der Priorisierung und Behebung von Schwachstellen.