#Künstliche Intelligenz · 3 Min. Lesezeit · Tim Rinkel

KI-PROXY-HAMMER! LiteLLM-Lücke verschluckt deine API-Keys – so stoppst du den Diebstahl JETZT!

KI-PROXY-HAMMER! LiteLLM-Lücke verschluckt deine API-Keys – so stoppst du den Diebstahl JETZT!

22.000 GitHub-Sterne, 9.3 CVSS, ein einziger HTTP-Header. Das ist die bittere Bilanz von CVE-2026-42208 in LiteLLM, dem Lieblings-Proxy für alle, die OpenAI, Claude und Co. unter einer URL bündeln.

GEFAHR! Authorization-Header als SQL-Schleuder

Der Fehler steckt tief im Auth-Pfad. LiteLLM klebt den Bearer-Token direkt in den SELECT-Befehl gegen die Tabelle LiteLLM_VerificationToken. Keine Parameter-Bindings, kein Escaping. Wer einen passenden String einschleust, manipuliert das SQL-Statement – bevor er auch nur einen einzigen API-Call abgesetzt hat.

Sysdig nennt das Verhalten pre-authentication SQL injection. Heißt im Klartext: Du musst kein gültiger Nutzer sein. Du musst nur einen HTTP-Request schicken.

SCHOCK: 26 Stunden bis zum ersten Angriff

LiteLLM hat den Patch am 19. April mit Version 1.83.7-stable ausgeliefert. Das GitHub-Advisory landete einen Tag später in der Datenbank. Schon am 26. April, um 16:17 UTC, schlug der erste Angreifer zu. Sysdig hat den Request mitgeschnitten.

Das Ziel war eindeutig: die Tabellen litellm_credentials.credential_values und litellm_config. Genau dort hinterlegen Admins ihre API-Schlüssel für OpenAI, Anthropic, Bedrock und Vertex. Klaut der Angreifer diese Keys, kann er auf Kosten des Opfers Token verbrennen, Modelle abfragen oder Infrastruktur kapern.

So sicherst du deinen KI-Proxy in 10 MINUTEN

  1. Update einspielen. Mit pip install -U litellm oder über Docker ein Image auf 1.83.7-stable oder neuer ziehen.
  2. Provider-Keys rotieren. Bei OpenAI, Anthropic und Azure neue Keys generieren, die alten widerrufen. Egal ob du Spuren findest oder nicht.
  3. Datenbank prüfen. Suche nach unbekannten neuen Tokens in LiteLLM_VerificationToken. Alles, was du nicht selbst angelegt hast, sofort löschen.
  4. Logs auf Anführungszeichen scannen. Ein simpler grep auf ' oder UNION im Authorization-Header reicht meist, um Angriffsversuche zu finden.

EXTRA-TIPP: Pre-Auth-Endpunkte gehören hinter ein WAF

LiteLLM gehört nicht direkt ins Internet. Pack einen Reverse-Proxy mit Rate-Limiting und SQLi-Filter davor. Cloudflare, Caddy mit Coraza oder ein nginx mit ModSecurity erledigen das in zehn Minuten. Damit fängst du mindestens die Standard-SQLi-Payloads ab, bevor sie überhaupt am Auth-Code ankommen.

FAZIT: Wer KI-Proxys hostet, hostet auch Geld

CVE-2026-42208 ist ein typischer 2026er-Vorfall: Ein Proxy, der eigentlich Komfort bringen sollte, wird zum Schlüsselbund-Diebstahl-Service, sobald jemand einen Header-Trick findet. Updaten, Keys rotieren, Logs lesen – das ist die Hausaufgabe für dieses Wochenende.

Häufige Fragen

Welche Versionen sind betroffen?
Verwundbar sind LiteLLM-Versionen ab 1.81.16 bis einschließlich 1.83.6. Der Fix kam am 19. April 2026 mit der Version 1.83.7-stable. Wer den Proxy seit Februar aktualisiert hat, sitzt auf einer der angreifbaren Builds. Containerimages mit dem Tag latest haben den Patch in der Regel automatisch gezogen, Self-Build-Setups nicht.
Wie merke ich, ob ich verwundbar bin?
Prüfe per litellm --version oder am Container-Tag, welche Version läuft. Liegt sie unter 1.83.7, ist der Proxy angreifbar. Außerdem in den Webserver-Logs nach Authorization-Headern mit Anführungszeichen, Klammern oder UNION-Statements suchen – das sind klassische SQLi-Versuche.
Wie behebe ich das konkret?
Auf 1.83.7-stable oder neuer aktualisieren, Container neu deployen, Datenbank-Credentials und alle hinterlegten Provider-Keys (OpenAI, Anthropic, Azure, Bedrock, Vertex, …) rotieren. Wer den Proxy public exposiert hat, schaltet ihn am besten kurz hinter ein WAF mit SQLi-Regeln, bis das Update läuft.
Gab es schon aktive Angriffe?
Ja. Sysdig dokumentiert den ersten Angriff am 26. April um 16:17 UTC, also rund 26 Stunden nach Veröffentlichung der GitHub-Advisory. Die Angreifer haben gezielt Tabellen wie litellm_credentials.credential_values abgegriffen – also genau die Tabelle, in der die Provider-API-Keys liegen.
Was bedeutet das für meine OpenAI- oder Anthropic-Rechnung?
Wer Provider-Keys über einen verwundbaren Proxy bezahlt hat, sollte die Abrechnungsportale gezielt nach unbekannten Modellen, Regionen oder Spitzen seit Mitte April durchsehen. Anthropic, OpenAI und Azure protokollieren API-Aufrufe nach Schlüssel – auffällige Muster sofort melden und Schlüssel widerrufen lassen.

Quellen