BerriAI LiteLLM: SQL-Injection (CVE-2026-42208)

Was ist betroffen, was ist zu tun

LiteLLM ist ein Proxy-Server (AI Gateway), um LLM-APIs im OpenAI-Format (oder nativ) aufzurufen. Von Version 1.81.16 bis vor Version 1.83.7 wurde während der API-Schlüsselüberprüfungen durch den Proxy eine Datenbankabfrage verwendet, die den vom Aufrufer bereitgestellten Schlüsselwert in den Abfragetext einmischte, anstatt ihn als separaten Parameter zu übergeben.

Die Schwachstelle wird aktiv ausgenutzt; behandeln Sie sie vorrangig. Aktualisieren Sie litellm auf Version 1.83.7, LiteLLM auf Version 1.83.7. Sofortmaßnahmen, Mitigation und Erkennungsregeln stehen im Runbook unten.

Betroffen

• BerriAI LiteLLM gte 1.81.16, < 1.83.7..*

Unklar, ob und wie Sie betroffen sind? Frage zu dieser Schwachstelle stellen

Metriken

Behebung und Mitigation

1. 01

   Schritt 1 im Runbook

   Sofort-Response (0-24 h)

   • Inventarisierung: Alle LiteLLM-Proxy-Instanzen ermitteln (PyPI-Paket litellm, Container-Images ghcr.io/berriai/litellm*, Helm-Deployments, Entwickler-VMs). Versionen prüfen mit pip show litellm bzw. Image-Tag. Betroffen sind 1.81.16 bis einschließlich aller Versionen vor 1.83.7, darunter 1.82.1, 1.82.3, 1.82.4, 1.82.5 und 1.82.6.
   • Patch einspielen: Auf LiteLLM 1.83.7 oder neuer aktualisieren. Das gilt für Container-Image und PyPI-Paket gleichermaßen. Nach dem Rollout per Health-Check und Versionsabfrage verifizieren, dass keine Alt-Replikas mehr laufen. Rolling-Update-Reste in Kubernetes gezielt prüfen.
   • Exposition sofort reduzieren: Ist der Proxy aus dem Internet oder aus breiten Client-Netzen erreichbar (Standard-Port 4000, im eigenen Deployment verifizieren), den Zugriff bis zum Patch auf bekannte Anwendungs-Server per Security Group, Firewall oder Ingress-Allowlist einschränken.
   • Geheimnisse rotieren: Bei jeder bislang exponierten, verwundbaren Instanz von einer Kompromittierung der Proxy-Datenbank ausgehen. Zu rotieren sind:
     • LITELLM_MASTER_KEY und alle Virtual Keys;
     • sämtliche im Proxy hinterlegten Upstream-Provider-Schlüssel (OpenAI, Azure OpenAI, Anthropic, Bedrock usw.);
     • die Datenbank-Zugangsdaten (DATABASE_URL). Die Provider-Schlüssel immer beim Anbieter widerrufen, nicht nur lokal ersetzen.
   • Beweissicherung: Vor dem Neuaufbau einen Snapshot der PostgreSQL-Datenbank sowie Proxy- und Reverse-Proxy-Logs sichern. Dasselbe gilt für Cloud-Billing-Daten der LLM-Provider. Das ist Grundlage für die Prüfung einer NIS2-Meldepflicht innerhalb der 24-h-Frühwarnfrist.
2. 02

   Schritt 2 im Runbook

   Mitigation-Layer

   • Netzsegmentierung: Den LiteLLM-Proxy ausschließlich in einem internen Anwendungssegment betreiben. Die zugehörige PostgreSQL-Instanz darf nur vom Proxy-Host erreichbar sein (Port 5432 nicht routbar aus Client-VLANs). Ausgehenden Verkehr des Proxys auf die tatsächlich genutzten Provider-Endpunkte beschränken.
   • WAF-/Reverse-Proxy-Regel: Den Authorization-Header vor dem Proxy strikt validieren. Nur Bearer sk-[A-Za-z0-9_-]+ zulassen (an das eigene Key-Format anpassen), alles andere mit 400 abweisen. Zusätzlich Header mit SQL-Metazeichen und Schlüsselwörtern blockieren: ', --, ;, /*, UNION, SELECT, pg_sleep, CHR(, ||. Beispiel ModSecurity: SecRule REQUEST_HEADERS:Authorization "@rx (?i)('|--|;|union|select|pg_sleep)" "id:1042208,phase:1,deny,status:400".
   • Datenbank-Härtung (Least Privilege): Die DB-Rolle des Proxys auf das eigene Schema beschränken. Kein Superuser, kein CREATE ROLE, kein Zugriff auf pg_read_file, COPY ... PROGRAM oder fremde Datenbanken. Eine gemeinsam genutzte PostgreSQL-Instanz mit anderen Fachanwendungen vermeiden, da die SQL-Injection sonst den Wirkungsradius erweitert.
   • Schlüssel-Hygiene: Provider-Schlüssel mit minimalen Berechtigungen und Ausgabelimits versehen (Budget-Caps, Projekt-Keys). Wo möglich, Workload Identity oder Managed Identity statt statischer Schlüssel nutzen, damit ein Datenbankabzug keine langlebigen Geheimnisse liefert.
   • Admin-Oberfläche: Admin-UI und Management-Routen (/key/*, /user/*, /team/*, /ui) nicht öffentlich exponieren. Nur aus dem Admin-Netz bzw. über VPN mit MFA zulassen.
3. 03

   Schritt 3 im Runbook

   Detection-Regeln

   • Reverse-Proxy-/WAF-Logs: Authorization-Header mit ungewöhnlicher Länge oder SQL-Syntax auf LLM-Routen (/chat/completions, /v1/chat/completions, /completions, /embeddings). Header-Logging am vorgelagerten Proxy temporär aktivieren und den Zugriff auf diese Logs schützen. KQL-Skizze: WafLogs | where Uri has "completions" and AuthHeader matches regex @"(?i)('|--|union|select|pg_sleep)".
   • Antwortmuster: Häufungen von 401/500-Antworten oder auffällig variierenden Antwortzeiten von einer Quell-IP auf LLM-Routen deuten auf Blind- bzw. Time-based-SQLi hin. SPL: index=proxy uri_path="*completions" status IN (401,500) | stats count, stdev(response_time) by src_ip | where count>50.
   • PostgreSQL-Logs: log_min_error_statement = error aktivieren und auf Syntaxfehler (syntax error at or near, unterminated quoted string) in Abfragen gegen Token-/Verification-Tabellen achten. Weitere Indikatoren in pg_stat_statements bzw. pgaudit: pg_sleep, UNION SELECT und Zugriffe auf information_schema.
   • Integrität der Proxy-Daten: Neu angelegte oder geänderte Virtual Keys, Benutzer mit Admin-Rolle und erhöhte Budgets außerhalb von Change-Fenstern als Alarm behandeln (Diff der Tabellen gegen den letzten bekannten Stand).
   • Missbrauch der Provider-Schlüssel: Nutzungs- und Kostenanomalien bei OpenAI, Azure, Anthropic oder Bedrock sowie API-Aufrufe von fremden IP-Adressen oder Regionen. Diese Signale weisen auf exfiltrierte Upstream-Schlüssel hin.

Erkennungsregeln

Für diese Schwachstelle liegt noch keine NEOSEC-Erkennungsregel vor.

Einordnung nach NIS2 und CRA

Regelbasierte Einordnung aus Ausnutzungsstatus und Schweregrad. Sie ersetzt keine Prüfung im Einzelfall.

NIS2

NIS2 ist die EU-Richtlinie (EU) 2022/2555 zur Erhöhung des Cybersicherheitsniveaus in der Union. Sie weitet Pflichten gegenüber der ersten NIS-Richtlinie deutlich aus: mehr Sektoren, verbindliches Risikomanagement, gestufte Meldepflichten und persönliche Verantwortung der Geschäftsleitung.

Im Glossar lesen

Aktiv ausgenutzt: Behandeln Sie die Schwachstelle im Schwachstellenmanagement nach Art. 21 Abs. 2 lit. e NIS2 vorrangig. Wird sie in Ihrer Umgebung ausgenutzt, prüfen Sie die Meldepflicht nach Art. 23 (Frühwarnung binnen 24 Stunden).

CRA

Der CRA ist die EU-Verordnung (EU) 2024/2847 mit horizontalen Cybersicherheitsanforderungen an „Produkte mit digitalen Elementen“ — von Industriesteuerungen über Software bis zu vernetzten Verbrauchergeräten. Erstmals müssen Hersteller Sicherheit über den gesamten Produktlebenszyklus gewährleisten, Schwachstellen behandeln und Sicherheitsupdates bereitstellen.

Im Glossar lesen

Seit dem 11.09.2026 müssen Hersteller betroffener Produkte mit digitalen Elementen aktiv ausgenutzte Schwachstellen nach Art. 14 CRA melden, mit Frühwarnung binnen 24 Stunden über die zentrale Meldeplattform der ENISA.

ISO/IEC 27001

ISO/IEC 27001 ist der international führende Standard für ein Informationssicherheits-Managementsystem (ISMS). Er beschreibt einen risikobasierten, prozessorientierten Rahmen, um Informationssicherheit systematisch zu planen, umzusetzen, zu überprüfen und zu verbessern.

Im Glossar lesen

Maßnahme A.8.8, Management technischer Schwachstellen: Relevanz für Ihre Systeme bewerten, Behebung einplanen und nachweisen.

Beschreibung

LiteLLM ist ein Proxy-Server (AI Gateway), um LLM-APIs im OpenAI-Format (oder nativ) aufzurufen. Von Version 1.81.16 bis vor Version 1.83.7 wurde während der API-Schlüsselüberprüfungen durch den Proxy eine Datenbankabfrage verwendet, die den vom Aufrufer bereitgestellten Schlüsselwert in den Abfragetext einmischte, anstatt ihn als separaten Parameter zu übergeben. Ein unauthentifizierter Angreifer könnte einen speziell gestalteten Autorisierungsheader an jede LLM-API-Route senden (zum Beispiel POST /chat/completions) und diese Abfrage über den Fehlerbehandlungs-Pfad des Proxys erreichen. Ein Angreifer könnte Daten aus der Datenbank des Proxys lesen und möglicherweise ändern, was zu unbefugtem Zugriff auf den Proxy und die von ihm verwalteten Anmeldeinformationen führen kann. Dieses Problem wurde in Version 1.83.7 behoben.

Quelle: NVD (NIST), OSV (Open Source Vulnerabilities), CISA KEV Catalog, CVE.org (MITRE), pwn.watch, cvelistv5, ENISA EUVD, BSI WID Portal, BSI CSAF

Hersteller und Produkte

• BerriAI BerriAI LiteLLM
• LiteLLM LiteLLM
• Open Source Litellm

Weakness-Klassen (CWE)

• CWE-89Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

  Base

  The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.

  Eintrag bei MITRE CWE-89

• CWE-89Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

  Base

  The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.

  Eintrag bei MITRE CWE-89

Quellen & Referenzen

• github.comBerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmcweb, x_refsource_CONFIRM, pwn-watch, Mitigation, Patch, Herstellerhinweis
• NVD (NIST)NVD: CVE-2026-42208advisory, pwn-watch
• github.comBerriAI/litellmpackage
• github.comBerriAI/litellm/releases/tag/v1.83.7-stableweb, x_refsource_MISC, Produkt, Release Notes
• cisa.govknown-exploited-vulnerabilities-catalog?field_cve=CVE-2026-42208web, government-resource, US-Behörde
• pypi.orgproject/litellmpackage
• GitHub Security Advisoriesadvisories/GHSA-r75f-5x8p-qvmcadvisory
• access.redhat.comsecurity/cve/CVE-2026-42208Schwachstellendatenbank, x_refsource_REDHAT, Hinweis Dritter
• bugzilla.redhat.comRHBZ#2463965Issue-Tracker, x_refsource_REDHAT, Mitigation, Hinweis Dritter
• security.access.redhat.comdata/csaf/v2/vex/2026/cve-2026-42208.jsonx_sadp-csaf-vex, Hinweis Dritter
• github.compypa/advisory-database/tree/main/vulns/litellm/PYSEC-2026-391.y…web
• pwn.watchpwn.watch: BerriAI LiteLLM: BerriAI LiteLLM SQL Injection Vulnerabilitypwn-watch
• cisa.govCISA Known Exploited Vulnerabilities Catalogpwn-watch

Änderungen an der CVE

Wer diese CVE wann geändert hat: die NVD (Analyse, betroffene Produkte, CVSS), der Herausgeber der CVE (CNA) und ergänzende Stellen wie CISA (ADP).

1. 29.06.2026Analyse der NVD geändertNVD

   Neue Referenzen:

   • https://access.redhat.com/security/cve/CVE-2026-42208
   • https://bugzilla.redhat.com/show_bug.cgi?id=2463965
   • https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-42208.json
   3 Einzeländerungen im Original anzeigen

   Einzeländerungen dieses Ereignisses im Original der NVD

   Art	Aktion	Vorher	Nachher
   Referenztyp	ergänzt	—	redhat-SADP: https://access.redhat.com/security/cve/CVE-2026-42208 Types: Third Party Advisory
   Referenztyp	ergänzt	—	redhat-SADP: https://bugzilla.redhat.com/show_bug.cgi?id=2463965 Types: Mitigation, Third Party Advisory
   Referenztyp	ergänzt	—	redhat-SADP: https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-42208.json Types: Third Party Advisory

   Kennung der Quelle: nvd@nist.gov

Eine Übersetzung der NVD in eine andere Sprache ist ausgeblendet.

Verknüpfte Advisories

• Fwd: @RISK®: The Consensus Security Vulnerability Alert: Vol. 26, Num. 20SANS @RISK21.05.2026
• Fwd: @RISK®: The Consensus Security Vulnerability Alert: Vol. 26, Num. 19SANS @RISK14.05.2026