Die kritische Sicherheitsluecke CVE-2026-42208 im beliebten AI-Gateway LiteLLM von BerriAI wird bereits aktiv ausgenutzt. Weniger als 36 Stunden nach der Offenlegung des Sicherheitsavis begannen Angreifer, die Schwachstelle fuer den Diebstahl sensibler Daten und von Zugangs-Schluesseln zu grossen Sprachmodellen (LLM-Providern) zu missbrauchen.
Hintergrund zur LiteLLM-Sicherheitsluecke CVE-2026-42208
Die Schwachstelle CVE-2026-42208 wurde mit einem Basiswert von CVSS 9.3 als kritisch eingestuft und gehoert zur Klasse der SQL-Injection-Angriffe. Ursache ist ein Fehler im Mechanismus zur Pruefung von Proxy-API-Schluesseln: Das vom Client gelieferte Token wurde direkt in einen SQL-String eingebettet, statt es ueber sichere, parametrisierte Abfragen an die Datenbank von LiteLLM zu uebergeben.
Nach Analyse der Maintainer kann ein nicht authentifizierter Angreifer einen speziell gestalteten Authorization-Header an beliebige LLM-Endpunkte (etwa POST /chat/completions) senden. Ueber einen Fehlerpfad in der Verarbeitung von Ausnahmen landet dieser Wert schliesslich in einer verwundbaren SQL-Abfrage. Damit wird sowohl das Auslesen als auch potenziell die Manipulation von Datensaetzen ermoeglicht – mit der Folge eines vollstaendig unautorisierten Zugriffs auf den Proxy und die dort verwalteten Zugangsdaten.
Betroffen sind alle LiteLLM-Release-Staende vor Version 1.83.7-stable, in der die Entwickler die SQL-Injection am 19. April 2026 behoben haben. Die exakte Liste der Versionen ist im offiziellen GitHub-Sicherheitshinweis GHSA-r75f-5x8p-qvmc dokumentiert.
Technische Ursache: SQL-Injection vor der Authentifizierung
SQL-Injection beschreibt Angriffe, bei denen ungepruefte Eingaben in SQL-Befehle einfliessen und so eigene Anweisungen in der Datenbank ausgefuehrt werden koennen. Im Fall von LiteLLM war die Fehlerbehandlung und Protokollierung die kritische Komponente: Der Inhalt des Authorization-Headers wurde ungefiltert in ein SQL-Statement geschrieben. Dadurch konnten Angreifer die Struktur der Abfrage veraendern, weitere Spalten und Tabellen auslesen oder Aenderungsoperationen ausfuehren – und das noch bevor eine gueltige Authentifizierung stattgefunden hatte.
Nachgewiesene Ausnutzung und Verhalten der Angreifer
Nach Angaben des Sicherheitsunternehmens Sysdig wurde die erste Exploit-Aktivitaet am 26. April 2026 um 16:17 UTC beobachtet – rund 26 Stunden nach der Indexierung des GitHub-Advisory in der GitHub Advisory Database und innerhalb eines 36-Stunden-Fensters nach der oeffentlichen Bekanntmachung der Schwachstelle. Ausgangspunkt war die IP-Adresse 65.111.27[.]132.
Der Angriff verlief zweiphasig: Zunaechst wurden mehrere SQL-Injection-Versuche von einem Egress-IP vorgenommen. Rund 20 Minuten spaeter wechselte der Operator auf 65.111.25[.]67 und setzte die Tests fort, ergaenzt um kurze, nicht authentifizierte Zugriffe auf Endpunkte zur Schluesselverwaltung. Im Fokus standen die Tabellen litellm_credentials.credential_values und litellm_config, die LLM-Provider-Schluessel und Laufzeitkonfigurationen enthalten. Dass keine Zugriffe auf litellm_users oder litellm_team beobachtet wurden, deutet auf gezielte Jagd nach Geheimnissen und ein gutes Vorwissen ueber das Datenbankschema hin.
Warum eine kompromittierte LiteLLM-Datenbank besonders gefaehrlich ist
LiteLLM ist ein weit verbreitetes Open-Source-AI-Gateway mit mehr als 45.000 GitHub-Sternen und rund 7.600 Forks. Die Plattform abstrahiert die APIs verschiedener LLM-Provider und buendelt deren Zugriff an einer zentralen Stelle. In einer einzigen Zeile der Tabelle litellm_credentials koennen daher gleich mehrere hochkritische Geheimnisse liegen.
Sysdig weist darauf hin, dass ein Eintrag typischerweise etwa einen OpenAI-Organisationsschluessel mit erheblichen Budgetgrenzen, einen Anthropic-Admin-API-Schluessel sowie AWS-Bedrock-IAM-Zugangsdaten enthalten kann. Ein erfolgreicher Dump der Datenbank kommt damit praktisch einer Teilkompromittierung kompletter Cloud-Accounts gleich. Branchenberichte wie der Verizon Data Breach Investigations Report betonen seit Jahren, dass der Diebstahl von Zugangsdaten zu den haeufigsten Einfallstoren in Cloud-Umgebungen gehoert; LLM-API-Schluessel stellen hier keine Ausnahme dar.
Hinzu kommt, dass LiteLLM erst kurz zuvor Ziel eines Supply-Chain-Angriffs durch die Gruppe TeamPCP war, der auf den Diebstahl von Geheimnissen in Downstream-Projekten abzielte. In Kombination zeigt dies, dass KI-Infrastruktur und AI-Gateways zunehmend zu priorisierten Zielen professioneller Angreifer werden – ein Trend, den Initiativen wie die OWASP Top 10 for LLM Applications explizit adressieren.
Risikoanalyse und strategische Implikationen fuer AI-Sicherheit
Auch wenn CVE-2026-42208 keine direkte Remote-Code-Ausfuehrung ermoeglicht, ist der vorauthentifizierte Datenbankzugriff hochkritisch. Kompromittierte LLM-Schluessel koennen fuer Datenabfluss, umfangreiche Prompt-Manipulation, den Aufbau von Phishing-Infrastrukturen oder zur Generierung erheblicher Cloud-Kosten missbraucht werden. Zudem eroeffnen sie Angreifern zusaetzliche Einfallstore fuer laterale Bewegungen in verbundene Cloud-Services.
Der Fall GHSA-r75f-5x8p-qvmc bestaetigt eine zentrale Beobachtung von Projekten wie Zero Day Clock: Das Zeitfenster zwischen Offenlegung und erster praktischer Ausnutzung betraegt bei populärer Open-Source-Software oft nur noch Stunden. Angreifern genuegen haeufig bereits ein oeffentliches Advisory und ein einsehbares Datenbankschema; veroeffentlichter Exploit-Code ist nicht mehr zwingend erforderlich. Patch-Management, Monitoring und Secret-Management muessen sich explizit an diesem beschleunigten Bedrohungsmodell orientieren.
Konkrete Schutzmassnahmen fuer LiteLLM-Umgebungen
Sofortmassnahmen: Patching, Workaround und Incident Response
Administrierende sollten LiteLLM umgehend auf Version 1.83.7-stable oder neuer aktualisieren, um die SQL-Injection nachhaltig zu schliessen. Wenn ein sofortiges Update voruebergehend nicht moeglich ist, empfehlen die Entwickler den Workaround, in den general_settings den Parameter disable_error_logs: true zu setzen. Dadurch wird der verwundbare Fehlerpfad deaktiviert, allerdings zulasten der Protokollierung; diese Option sollte daher ausschliesslich als temporare Notmassnahme dienen.
Parallel dazu sind klassische Incident-Response-Schritte angezeigt: eine Auswertung der LiteLLM-Logs auf auffaellige LLM-Anfragen und moegliche SQL-Fehlermuster, die Rotation saemtlicher in LiteLLM gespeicherter API-Schluessel und Zugangsdaten (OpenAI, Anthropic, AWS Bedrock u.a.) sowie die Pruefung auf ungewoehnliche Aktivitaeten und Kostenentwicklungen in den angebundenen Cloud-Konten.
Langfristige Sicherheitsstrategien fuer AI-Gateways
Ueber das Patching hinaus sollten LiteLLM-Instanzen netzwerktechnisch gehärtet werden: Zugriffsbeschraenkung ueber IP-Filter, VPN oder einen konsequenten Zero-Trust-Ansatz reduziert die Angriffsoberflaeche erheblich. API-Schluessel gehoeren in dedizierte Secret-Management-Loesungen (z.B. Vault, KMS), mit strikt begrenzten Rechten nach dem Prinzip der minimalen Privilegien.
Weiterhin ist es ratsam, SAST- und DAST-Scans nicht nur auf klassische Webanwendungen, sondern explizit auf Komponenten der KI-Infrastruktur auszuweiten. Ergaenzt um engmaschiges Monitoring und Alarme fuer ungewoehnliche LLM-Nutzung, API-Fehler und Kostenpeaks laesst sich das Risiko künftiger Angriffe auf AI-Gateways signifikant reduzieren.
Die Sicherheitsluecke CVE-2026-42208 in LiteLLM fuehrt eindruecklich vor Augen, dass AI-Gateways und LLM-Proxies als kritische Infrastruktur behandelt werden muessen. Organisationen, die produktiv auf generative KI setzen, sollten Patch-Prozesse beschleunigen, Geheimnisse strikt segmentieren und Sicherheitspruefungen fruehzeitig in die Entwicklung integrieren. Wer jetzt in robuste Schutzmassnahmen investiert, reduziert nicht nur das Risiko kostspieliger Vorfaelle, sondern schafft zugleich eine belastbare Grundlage fuer den sicheren Einsatz von KI in Geschaeftsprozessen.
