LiteLLM nach den Vorfällen 2026 sicher produktiv betreiben

Ist LiteLLM nach den Vorfällen 2026 noch sicher

Ja, sofern Sie es als kritischen Dienst behandeln und zuverlässig patchen und prüfen können. Die Vorfälle waren real, doch jeder betraf klar abgegrenzte Versionen und hatte einen klaren Ausweg. Zwei richteten sich gegen den Vertriebsweg von LiteLLM, einer war ein Fehler im Code. Die Tabelle fasst sie nach den Vorfallberichten von LiteLLM und dem CVE-Eintrag zusammen, Stand 7. November 2026.

Der Oktober-Vorfall enthält die nützlichste Lehre für den Betrieb. Laut der Ursachenanalyse von LiteLLM begann er mit einem Admin-Schlüssel für eine interne Instanz der LiteLLM Agent Platform, der am 27. Mai 2026 in ein öffentliches Repository gelangte und mehr als vier Monate später noch gültig war. Über diesen Dienst erhielt der Angreifer ein GitHub-Token eines Organisationsinhabers. Auch die Signatur half nicht: Die schädlichen Images trugen eine gültige Signatur des vorherigen Schlüssels, weshalb LiteLLM rät, zusätzlich die Digests zu prüfen. Wir lesen daraus, dass Sie bei jedem Gateway dieselben Gewohnheiten schützen: exakte Artefakte pinnen, Schlüssel kurzlebig halten und bemerken, wenn sich etwas ändert, das Sie betreiben. LiteLLM hat inzwischen eine Liste von Änderungen an Release-Pipeline, Identitäten und Erkennung veröffentlicht.

So prüfen Sie, ob Sie betroffen waren

Beginnen Sie mit einer Bestandsaufnahme aller Orte, an denen LiteLLM läuft: Proxy-Deployments, CI-Jobs, Entwicklerrechner und jede Python-Anwendung, die das SDK importiert. Gehen Sie dann jeden Vorfall anhand dieser Liste durch.

1. 1

   Versionen und Digests erfassen

   Halten Sie für jedes Deployment die LiteLLM-Version und den Digest des laufenden Images fest. Der kann vom Tag in Ihrem Manifest abweichen. In einer Python-Umgebung, die 1.107.0 enthalten könnte, rät LiteLLM davon ab, mit pip install zu beginnen, weil jeder Python-Start dort den Schadcode erneut ausführen kann. Prüfen Sie stattdessen die Dateien in site-packages.

2. 2

   März: nach 1.82.7 und 1.82.8 suchen

   Durchsuchen Sie CI-Logs, Build-Logs und Lockfiles nach diesen Versionen und site-packages nach einer Datei namens litellm_init.pth. LiteLLM nennt außerdem ausgehende Anfragen an models.litellm.cloud und checkmarx.zone als Indikatoren, und der Vorfallbericht legt 10:39 bis 16:00 UTC am 24. März 2026 als Prüfzeitraum zugrunde.

3. 3

   CVE-2026-42271: Versionen und Endpunktaufrufe prüfen

   Jeder Proxy ab 1.74.2 bis ausschließlich 1.83.7 war verwundbar. War einer für Personen oder Dienste erreichbar, denen Sie nicht voll vertrauen, durchsuchen Sie die Access-Logs nach POST-Anfragen an /mcp-rest/test/connection und /mcp-rest/test/tools/list und behandeln Sie unerwartete Aufrufe als Kompromittierung des Hosts. Diese Log-Prüfung schlagen wir selbst vor. Ein Verfahren des Herstellers dafür gibt es nicht.

4. 4

   Oktober: nach 1.107.0 und seinen Dateien suchen

   Suchen Sie nach litellm 1.107.0, den Dateien cook.pth, cook.py und sitecustomize.py in site-packages, einem Python-Prozess, der /tmp/remote_code_loader.lock hält, und dem von LiteLLM als Indikator veröffentlichten Image-Digest. LiteLLM weist darauf hin, dass ein leerer Befund wenig beweist, weil Container und temporäre Verzeichnisse schon bereinigt sein können. Prüfen Sie daher auch, ob ein Deployment am 21. Oktober latest, main-latest, main-stable oder v1.107.0 gezogen hat.

5. 5

   Rotieren, was der Host erreichen konnte

   Wo eine Betroffenheit plausibel ist, bauen Sie aus einer bekannt guten Version neu und rotieren alles, was der Host erreichen konnte. Für den Oktober nennt LiteLLM die Instanz- oder Task-Rolle, jeden in der Proxy-Datenbank gespeicherten Anbieter-Schlüssel, Master- und virtuelle Schlüssel, das Datenbankpasswort und jedes Geheimnis in der Umgebung eines Prozesses auf dem Host. Widerrufen Sie die alten Zugangsdaten, statt nur neue auszustellen.

Brauchen Sie Redis und Postgres

Postgres brauchen Sie, sobald Sie virtuelle Schlüssel ausgeben, Redis, sobald mehr als ein Worker-Prozess Anfragen bedient. Virtuelle Schlüssel setzen bei LiteLLM eine Postgres-Datenbank voraus, die über DATABASE_URL angebunden wird. Laut der Seite zu den Redis-Anforderungen ist Redis für jedes Deployment mit mehr als einem Worker dringend empfohlen. Dazu zählt ein einzelner Container mit mehreren Workern ebenso wie ein Kubernetes-Deployment mit mehr als einem Replikat. Ohne Redis führt jeder Worker seinen eigenen Zustand:

• Rate Limits werden pro Worker gezählt. Im Beispiel der Dokumentation lässt ein Limit von 100 Anfragen pro Minute bei vier Workern 400 durch
• Harte Budgets können überschritten werden, weil parallele Anfragen auf verschiedenen Workern gezählt werden, bevor die Datenbank nachzieht
• Gelöschte Schlüssel, geänderte Budgets und Teamänderungen erreichen andere Worker erst, wenn deren lokaler Cache-Eintrag abläuft. Ein widerrufener Schlüssel bleibt also auf Workern nutzbar, die den Widerruf nicht verarbeitet haben
• Treffer im Antwort-Cache gibt es nur auf dem Worker, der die Antwort gespeichert hat
• Die SSO-Anmeldung an der Admin-UI kann scheitern, wenn die Weiterleitung des Browsers bei einem anderen Worker landet als dem, der sie gestartet hat

Der dritte Punkt ist die übliche Antwort auf die Frage, warum widerrufene Schlüssel noch eine Weile funktionieren. Die Einstellung user_api_key_cache_ttl legt fest, wie viele Sekunden Schlüssel im Arbeitsspeicher zwischengespeichert werden, und ein gemeinsamer Zustand in Redis sorgt dafür, dass ein Widerruf für alle Worker gilt. Schreiben Sie einen Offboarding-Test, der einen Schlüssel widerruft und danach jedes Replikat damit aufruft, und lassen Sie ihn vor dem Go-live und nach jedem Update laufen. Die Dokumentation weist zudem darauf hin, dass REDIS_HOST und REDIS_PORT als Umgebungsvariablen allein nicht genügen: Sowohl die Router-Einstellungen als auch der Cache-Block müssen auf Redis zeigen.

Für LiteLLM auf Kubernetes empfiehlt die Seite zu Production Best Practices einen Uvicorn-Worker pro Pod und Skalierung über Pods, als Untergrenze etwa 1 vCPU und 4 GiB Arbeitsspeicher pro Worker, Redis 7.0 oder neuer ab mehr als einer Instanz und eine Obergrenze für Datenbankverbindungen über database_connection_pool_limit mit dem Standardwert 10. Der Readiness-Endpunkt /health/readiness liefert auch bei nicht erreichbarer Datenbank weiter 200, die Pods bleiben also im Dienst. Entscheiden Sie bewusst, ob das dem Verhalten entspricht, das Sie bei einem Datenbankausfall wollen.

Versionen pinnen, prüfen und aktualisieren

Pinnen Sie den Image-Digest, prüfen Sie die Signatur und stellen Sie eine Umgebung nach der anderen um, nachdem Ihre eigenen Regressionstests bestanden sind. Die Seite zur Image-Sicherheit von LiteLLM empfiehlt Digest-Pinning, weil es den genauen Image-Inhalt unabhängig von Tag-Änderungen festlegt, warnt vor latest in Produktion und hat main-stable und main-latest abgekündigt. Images auf GHCR werden seit v1.83.0 mit cosign signiert. Nach dem Oktober-Vorfall hat LiteLLM den Signaturschlüssel gewechselt und rät, dem alten Schlüssel nur für Images zu vertrauen, die vor 1.107.0 veröffentlicht wurden. Nach unserem Verständnis wäre ein per Digest gepinntes Deployment während des Oktober-Vorfalls auf seinem bisherigen Image geblieben, egal wohin die Tags zeigten.

Auch der Release-Rhythmus hat sich geändert. Stand 7. November 2026 erscheinen Release Candidates und stabile Releases wöchentlich dienstagmorgens, beginnend mit der Woche vom 2. November 2026, und Release Candidates erhalten vor der Freigabe ein siebentägiges Zeitfenster für frühe Tester. LiteLLM empfiehlt, die Produktion auf das neueste stabile Release zu pinnen. Zudem erprobt LiteLLM einen Long-Term-Support-Zweig, beginnend mit 1.108, für einen Monat und hat die Regel, die vier jüngsten stabilen Linien zu patchen, für die Dauer des Pilots ausgesetzt. Prüfen Sie die Seite zur Versionsunterstützung, bevor Sie annehmen, dass Ihre Linie noch Fixes bekommt.

1. 1

   Ziel wählen und Release Notes lesen

   Wählen Sie ein stabiles Release, lesen Sie die Release Notes auf geänderte Standardwerte und notieren Sie den Digest. Zwei jüngere Beispiele: Seit 1.104.0 startet der Proxy nicht ohne starken Master-Schlüssel, und STDIO-MCP-Server sind aus, solange LITELLM_ENABLE_MCP_STDIO=true nicht gesetzt ist. Seit 1.105.0 ist die Route /sso/debug abgeschaltet.

2. 2

   Artefakt prüfen

   Führen Sie cosign verify gegen den öffentlichen Schlüssel aus einem gepinnten Commit aus, wie es die LiteLLM-Dokumentation zeigt, und vergleichen Sie den Digest mit dem notierten. Spiegeln Sie das geprüfte Image in Ihre eigene Registry, damit die Produktion nie von einem öffentlichen Tag zieht.

3. 3

   Regressionstests ausführen

   Spielen Sie in Staging einen festen Satz Anfragen pro Modellroute ab und prüfen Sie Statuscodes, Streaming, Tool-Aufrufe, Kosteneinträge, Schlüsselwiderruf und Budgetdurchsetzung. Der Long-Term-Support-Zweig von LiteLLM liefert Patches für die Übersetzung zu den Anbietern und für das Kosten-Tracking, was darauf hindeutet, wo Updates am häufigsten Verhalten ändern.

4. 4

   Schrittweise ausrollen

   Stellen Sie jeweils eine Umgebung oder einen Teil des Verkehrs um, beobachten Sie Fehlerraten und Latenz pro Anbieter und halten Sie den vorherigen Digest für ein Rollback bereit. Schemamigrationen können ein Rollback erschweren, sichern Sie daher vorher die Datenbank. Laut Produktionsleitfaden lässt sich mit DISABLE_SCHEMA_UPDATE verhindern, dass Pods Migrationen ausführen, sodass diese als eigener Schritt laufen.

LiteLLM sicher bereitstellen und Logs steuern

Machen Sie nur die Routen erreichbar, die Ihre Clients aufrufen, wenn möglich aus einem privaten Netz, und halten Sie alles Administrative intern. Das ist auch der Kern der Seite zu Security Best Practices von LiteLLM. In der Praxis heißt das:

• Betreiben Sie den Proxy hinter einem Ingress oder internen Load Balancer, mit Kubernetes-Network-Policies, die nur die Client-Namespaces hereinlassen und ausgehend nur Ihre Modellanbieter, Postgres und Redis erlauben
• Stellen Sie die Admin-UI nur unter einem internen Hostnamen oder per VPN bereit oder schalten Sie sie im öffentlichen Deployment mit DISABLE_ADMIN_UI=True ab. Sobald sich Admins per SSO oder als benannte Admin-Nutzer anmelden, setzen Sie disable_env_credential_login: true, denn sonst wirken UI_USERNAME und UI_PASSWORD als gemeinsamer Admin-Zugang, und ohne gesetztes UI_PASSWORD wird sogar der Master-Schlüssel akzeptiert
• Setzen Sie NO_DOCS, NO_REDOC und NO_OPENAPI gemeinsam auf True. Standardmäßig werden Swagger UI, ReDoc und das OpenAPI-Schema ohne Authentifizierung ausgeliefert, und wer nur eine Variable setzt, lässt die anderen lesbar
• Bewahren Sie Master-Schlüssel und LITELLM_SALT_KEY in einem Secret Store auf, geben Sie jeder Anwendung einen eigenen virtuellen Schlüssel und rotieren Sie den Salt-Schlüssel nicht mehr, sobald Zugangsdaten gespeichert sind, wie LiteLLM warnt
• Lassen Sie bei MCP die STDIO-Server abgeschaltet, sofern Sie sie nicht brauchen, und kennzeichnen Sie jeden MCP-Server ausdrücklich mit available_on_public_internet. Die Dokumentation ist beim Standardwert widersprüchlich, und als intern gilt ein Aufrufer nur, wenn seine IP-Adresse in mcp_internal_ip_ranges liegt
• Hinter einem Reverse Proxy setzen Sie PROXY_BASE_URL auf genau den https-Origin, den Nutzer sehen, damit Session-Cookies das Secure-Flag tragen

Logging und Aufbewahrung von Logs

Standardmäßig schreibt LiteLLM pro Anfrage ein Spend-Log und Fehler-Logs, speichert aber keine Inhalte von Prompts und Antworten. Mit store_prompts_in_spend_logs schalten Sie die Speicherung von Inhalten ein, mit disable_spend_logs wird das Schreiben von Spend-Logs in die Datenbank abgeschaltet. Die Aufbewahrungsfrist ist aus, bis Sie sie setzen: Ohne maximum_spend_logs_retention_period wird nie etwas gelöscht. Die Bereinigungseinstellungen funktionieren ohne Enterprise-Lizenz, und für die aggregierten täglichen Tag-Ausgaben gibt es eine eigene Aufbewahrungseinstellung. Gelöschte Zeilen geben keinen Speicherplatz an das Betriebssystem zurück, dimensionieren Sie den Postgres-Speicher also für die Spitze und nicht für den Normalbetrieb. Klären Sie mit Ihrem Datenschutzbeauftragten, ob Prompts überhaupt gespeichert werden dürfen. Ein Gateway, das Anfrageinhalte behält, enthält alles, was Clients senden, auch in Prompts eingefügte Zugangsdaten.

# config.yaml (excerpt)
general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  disable_env_credential_login: true
  store_prompts_in_spend_logs: false
  maximum_spend_logs_retention_period: "30d"
  maximum_spend_logs_cleanup_cron: "0 4 * * *"
  database_connection_pool_limit: 10

# Redis: both blocks are needed for multi-worker state
router_settings:
  redis_host: os.environ/REDIS_HOST
  redis_port: os.environ/REDIS_PORT
  redis_password: os.environ/REDIS_PASSWORD
litellm_settings:
  cache: true
  cache_params:
    type: redis
    host: os.environ/REDIS_HOST
    port: os.environ/REDIS_PORT
    password: os.environ/REDIS_PASSWORD

# Environment of the client-facing pods
LITELLM_MODE=PRODUCTION
NO_DOCS=True
NO_REDOC=True
NO_OPENAPI=True
DISABLE_ADMIN_UI=True

Welche Funktionen die Enterprise-Lizenz erfordern

Stand 7. November 2026 deckt das Open-Source-Gateway Routing, virtuelle Schlüssel und Spend-Logs ab. Ein Lizenzschlüssel auf demselben Image schaltet die Governance-Funktionen frei. Am häufigsten stoßen Teams zuerst auf SSO: Für die Admin-UI ist es bis zu fünf Nutzern kostenlos, darüber hinaus braucht es eine Enterprise-Lizenz. Laut LiteLLM richtet sich der Preis nach Deployment-Größe und Nutzung, es gibt eine 30-tägige Testphase, und der Bezug ist über die Marketplaces von AWS und Azure möglich. Die Tabelle stellt den Enterprise-Funktionen, die Sie am ehesten brauchen, einen Open-Source-Weg gegenüber. Die rechte Spalte ist unsere eigene Einschätzung.

Unsere Faustregel: Wenn Sie SSO für mehr als fünf Personen in der UI, Audit-Nachweise für Prüfer oder Aufsicht oder getrennte Log-Ziele pro Team brauchen, vergleichen Sie die Lizenz mit der Engineering-Zeit, die nötig ist, um diese Funktionen rund um das Gateway nachzubauen und über Updates hinweg funktionsfähig zu halten. In diesen Vergleich gehört noch ein Punkt. Laut der Seite zu Security Best Practices erhalten Enterprise-Kunden sieben Tage vor der öffentlichen Bekanntgabe eine E-Mail zu größeren Sicherheitsupdates. Das zählt, wenn Sie nicht innerhalb eines Tages patchen können.

Go-live-Checkliste für ein selbst gehostetes LiteLLM-Gateway

Bevor Sie LiteLLM für echten Verkehr selbst hosten, sollte jeder Punkt unten einen Verantwortlichen haben und nachweislich erledigt sein.

1. 1

   Version und Lieferkette

   Ein stabiles Release per Digest gepinnt, Signatur geprüft, Image in die eigene Registry gespiegelt und nirgends in Manifesten oder CI ein latest- oder main-stable-Tag.

2. 2

   Bekannte Vorfälle abgeschlossen

   Bestand auf 1.82.7, 1.82.8, 1.107.0 und jede Version unter 1.83.7 geprüft, mit dokumentierten Rotationen überall dort, wo eine Betroffenheit plausibel war.

3. 3

   Zustand

   Postgres mit Backups und getesteter Wiederherstellung, Redis 7.0 oder neuer für jedes Deployment mit mehr als einem Worker und ein Offboarding-Test, der auf jedem Replikat besteht.

4. 4

   Erreichbarkeit

   Admin-UI intern oder abgeschaltet, API-Dokumentation aus, Login über Umgebungs-Zugangsdaten aus, STDIO-MCP aus, jeder MCP-Server bewusst als öffentlich oder privat markiert, Network Policies aktiv.

5. 5

   Geheimnisse

   Master-Schlüssel, Salt-Schlüssel und Anbieter-Schlüssel im Secret Store, ein virtueller Schlüssel pro Anwendung mit Ablaufdatum und keine Anwendung, die den Master-Schlüssel nutzt.

6. 6

   Logs

   Aufbewahrungsfrist gesetzt, Speicherung von Prompts mit dem Datenschutz entschieden und Logs an Ihren Observability-Stack mit eigener Aufbewahrung übergeben.

7. 7

   Tests

   Regressionssuite pro Modellroute, ein Lasttest bei erwarteter Spitze mit Reserve und mindestens einmal geübtes Failover zwischen Anbietern.

8. 8

   Betrieb

   Eine benannte verantwortliche Person für Patches, die Sicherheitsmeldungen und Release Notes von LiteLLM verfolgt, eine Zielzeit für das Einspielen von Sicherheitsfixes und ein Runbook zum Rotieren aller Zugangsdaten, die das Gateway hält.

Cloudsail baut und betreibt LiteLLM auf Kubernetes-Clustern und in Cloud-Konten der Kunden, einschließlich Abnahmetests wie in dieser Checkliste.

LiteLLM-Gateway: Aufbau und BetriebLLM-Plattform-EngineeringQualitätssicherung für KI-Systeme