LiteLLM CVE-2026-42208: Unautorisierter Zugriff auf Datenbanken
Ein SQL-Injection in einem KI-Proxy-Layer ist kein normaler Web-App-Vuln. Wer LiteLLM als Routing-Schicht betreibt und noch nicht gepatcht hat, hat potenziell alle LLM-Provider-API-Keys exponiert – und jeden Prompt der je durch den Proxy gelaufen ist.
5 Min. Lesezeit
Das Wichtigste in Kürze
- CVSS 9.3 – Critical. CVE-2026-42208 erlaubt unauthenticated Angreifern Datenbankmodifikationen im LiteLLM Proxy Admin-Interface.
- Neue Attack Surface. KI-Proxies wie LiteLLM speichern Provider-API-Keys, Model-Routing-Konfigurationen und Prompt-Logs – alles in einer Datenbank.
- Kein Auth nötig. Der SQL-Injection-Angriff erfordert keine Authentifizierung – der Endpoint ist exposed wenn LiteLLM ohne Firewall betrieben wird.
- Incident-Response unterscheidet sich. Klassische Web-App-Playbooks passen nicht – der Blast Radius umfasst alle nachgelagerten LLM-Provider-Accounts.
- Sofortmaßnahme. Update auf gepatchte LiteLLM-Version, alle Provider-API-Keys rotieren und Proxy-Admin-Endpoint absichern.
Was ist LiteLLM? LiteLLM ist eine Open-Source-Python-Library und Proxy-Server der eine einheitliche API für über 100 LLM-Provider bereitstellt – OpenAI, Anthropic, Azure OpenAI, Google Gemini, Bedrock, Groq und viele weitere. Unternehmen nutzen LiteLLM als Middleware zwischen ihrer Anwendung und den verschiedenen Model-Providern: zentrales Key-Management, Usage-Tracking, Rate-Limiting und Load-Balancing. Kurz: LiteLLM ist genau das Tool das moderne KI-Infrastrukturen oft unsichtbar zusammenhält.
Der Vuln steckt im Admin-API-Endpoint des LiteLLM Proxys. Über SQL-Injection kann ein nicht authentifizierter Angreifer direkt die Datenbank modifizieren die LiteLLM für Konfiguration und Logging nutzt. Das ist nicht trivial: In dieser Datenbank liegen typischerweise die API-Keys aller konfigurierten Provider, die Routing-Regeln und – je nach Konfiguration – gecachte Prompts und Responses.
Warum KI-Proxy-Layer andere Incident-Response brauchen
Ein klassischer SQL-Injection in einer Web-App ist schlimm – meistens geht es um Kundendaten, Session-Token oder Zugangsdaten. Bei einem KI-Proxy ist das Schadenpotenzial strukturell anders:
- Provider-API-Keys mit hohem Blast Radius: LiteLLM verwaltet Keys für alle konfigurierten Provider. Ein gestohlener OpenAI-Key bedeutet unkontrollierte API-Nutzung auf Kosten des Unternehmens – und potenzieller Datenzugriff auf alle OpenAI-Projekte in diesem Account. Ein kompromittierter Anthropic-Key gibt Zugriff auf dasselbe.
- Routing-Manipulation: Wenn ein Angreifer Schreibzugriff auf die LiteLLM-Datenbank hat, kann er das Routing modifizieren – und Prompts an einen externen Endpoint umleiten. Das ist eine Form von Daten-Exfiltration die in klassischen SIEM-Regeln oft nicht auftaucht.
- Prompt-Logs als Sensitive Data: Viele LiteLLM-Deployments loggen Prompts und Responses für Debugging und Usage-Tracking. In der Praxis enthalten diese Logs interne Dokumentenextrakts, Kundenanfragen und proprietäre Geschäftsdaten.
- Downstream-Impact auf Anwendungen: Wenn ein Angreifer die Routing-Konfiguration ändert, können alle Anwendungen die den Proxy nutzen anfangen, Antworten von einem falschen Modell zu bekommen. Das ist schwer zu detecten und kann zu fehlerhaftem Verhalten in produktiven Systemen führen.
Was DevSecOps-Teams sofort prüfen müssen
| Sofortmaßnahme | Warum kritisch |
|---|---|
| LiteLLM auf gepatchte Version updaten | Schließt den SQL-Injection-Vektor |
| Alle Provider-API-Keys rotieren | Gestohlene Keys bleiben sonst gültig |
| Admin-Endpoint aus Public Internet entfernen | Admin-API war nie für Public-Access gedacht |
| LiteLLM-Logs auf anomale Routing-Änderungen prüfen | Zeigt ob ein Angreifer bereits Routing modifiziert hat |
| Provider-Accounts auf ungewöhnliche Usage prüfen | API-Key-Missbrauch erzeugt Kosten und hinterlässt Logs |
Der Admin-Endpoint ist das entscheidende Problem: LiteLLM wurde für interne Nutzung entwickelt. In Produktionsdeployments läuft der Proxy oft auf Port 4000, mit dem Admin-Interface exposed. Network-Segmentierung oder ein Reverse-Proxy der den Admin-Port blockiert sollte Standard-Setup sein – ist es aber nicht.
Häufige Fragen
Welche LiteLLM-Versionen sind von CVE-2026-42208 betroffen?
Die Vulnerability betrifft LiteLLM Proxy-Versionen vor dem Fix-Release der nach Bekanntwerden des CVE erschienen ist. Die genaue Versionsgrenze sollte der offiziellen CVE-Dokumentation und dem LiteLLM GitHub-Repository entnommen werden. Wer LiteLLM via pip installiert hat, kann mit pip install –upgrade litellm auf die aktuelle Version updaten.
Wie kann ich prüfen ob mein LiteLLM-Admin-Endpoint aus dem Internet erreichbar ist?
Prüfe ob Port 4000 des LiteLLM-Hosts von außen erreichbar ist. Eine einfache Methode: curl http://[host]:4000/health von einem externen Netzwerk. Wenn der Endpoint antwortet, ist er exposed. Der Admin-Endpoint sollte ausschließlich über interne Netzwerke oder VPN erreichbar sein. Nginx als Reverse-Proxy mit einer Deny-Regel für externe IPs auf Admin-Pfade ist die schnellste Härtungsmaßnahme.
Was tun wenn unklar ist ob ein Angriff stattgefunden hat?
Prüfe die LiteLLM-Datenbank-Logs auf unauthenticated API-Calls gegen den betroffenen Endpoint und auf ungewöhnliche Routing-Konfigurationsänderungen. Prüfe die Provider-Accounts (OpenAI, Anthropic etc.) auf API-Usage aus unbekannten IPs. Wenn Zweifel bestehen: alle Keys rotieren und als Worst-Case davon ausgehen dass Keys und Prompt-Logs kompromittiert sind.
Ist LiteLLM ein Einzelfall oder ist das ein allgemeines Problem in KI-Proxies?
KI-Proxies und LLM-Gateways sind eine relativ neue Software-Kategorie – LiteLLM, OpenRouter, PortKey, Helicone und andere. Sie entstanden schnell um den Bedarf an Unified-LLM-APIs zu decken, ohne den Security-Reifungszyklus durchlaufen zu haben den ältere Software-Kategorien hinter sich haben. Das macht sie zu einem strukturellen Blindspot in vielen Security-Teams die KI-Infrastruktur als „nur eine API“ behandeln.
Welche Monitoring-Regeln sollte ich für LiteLLM-Deployments einrichten?
Vier sinnvolle Monitoring-Regeln: (1) Alert bei jedem API-Call gegen den Admin-Endpoint von externen IPs. (2) Alert bei Routing-Konfigurationsänderungen in der LiteLLM-Datenbank. (3) Anomalie-Detection auf Provider-API-Usage – starke Abweichungen vom Baseline-Verbrauch. (4) Alert wenn LiteLLM-Logs aufhören – ein Angreifer der Zugriff hat könnte Logs deaktivieren.
Lesetipps der Redaktion
Mehr aus dem MBF Media Netzwerk
- → EU AI Act für SaaS-Anbieter: Was Hochrisiko-Klassifikation ab August bedeutet (cloudmagazin)
- → Industrial IoT Security 2026: Edge-Devices im NIS2-Audit-Scope (Digital Chiefs)
Quelle Titelbild: Pexels
