LiteLLM 1.94.2 schließt Token-Leak im MCP-Dashboard

LiteLLM 1.94.2 räumt eine unnötig riskante Stelle im MCP-Dashboard auf: Session-Daten für MCP-Server werden über den gemeinsamen Browser-Storage-Helfer abgelegt; ein refresh_token bleibt dabei nicht mehr im gespeicherten Payload. Für Teams mit true_passthrough oder oauth_delegate ist das ein kleiner, aber konkreter Hardening-Schritt.

Was das Release tatsächlich ändert

Die Release-PR beschreibt zwei Änderungen am Dashboard-Store: Der MCP-Session-Token-Store nutzt nun den zentralen Storage-Helfer, statt sein Payload als lesbaren Text abzulegen; außerdem enthält dieses Payload keinen Refresh-Token mehr. Betroffen ist der Pfad für MCP-Server, die OAuth delegieren oder Anfragen per Passthrough weiterreichen.

Das ist keine neue Authentifizierungsarchitektur und ersetzt weder serverseitige Zugriffskontrollen noch ein kurzes Token-Lifetime-Design. Es reduziert aber die Menge langlebiger Credential-Daten, die das Dashboard überhaupt im Browserzustand vorhält. Genau diese Reduktion ist bei Gateway-UIs wertvoll: Ein UI-Tab ist kein geheimer Tresor.

Auch der Terraform-Provider bekommt Sicherheitswartung

Parallel hebt LiteLLM im vendorten Terraform-Provider gRPC sowie golang.org/x-Module an. Laut zugehöriger Maintainer-PR hatte govulncheck vier von plugin.Serve erreichbare Advisories markiert; die aktualisierten Abhängigkeiten sollen diese Befunde beseitigen. Das ist für Plattformteams relevanter als ein gewöhnlicher Dependency-Bump, weil Provider häufig in automatisierten Deploy-Pipelines laufen.

Was Betreiber jetzt prüfen sollten

• Upgrade planen: insbesondere bei aktivem MCP-Dashboard und OAuth-delegierten Servern auf v1.94.2 wechseln.
• Browser-Sessions neu bewerten: Bestehende Sessions nicht als Sicherheitsgarantie behandeln; Token-Rotation und serverseitige Widerrufbarkeit bleiben Pflicht.
• Terraform-Pipeline testen: Provider-Update in einer Staging-Umgebung gegen die eigene LiteLLM-Konfiguration ausführen.
• Dashboard-Zugriff begrenzen: Admin-UI hinter SSO, kurzen Sessions und möglichst wenigen berechtigten Rollen betreiben.

Der wichtige Teil ist nicht, dass Browser-Storage plötzlich „sicher“ wäre. Der wichtige Teil ist, dass ein langlebiges OAuth-Artefakt dort weniger Angriffsfläche hat als zuvor.

Einordnung

LiteLLM sitzt in vielen Stacks an der Grenze zwischen Modellzugang, Teams, Schlüsseln und zunehmend MCP. Solche Releases sind selten spektakulär, aber operativ deutlich wertvoller als kosmetische Dashboard-Features: Sie entfernen Daten aus einem unnötig exponierten Pfad und aktualisieren eine Infrastrukturabhängigkeit mit konkret benannten Findings.

Quellen (Primärquellen, veröffentlicht am 8. August 2026): LiteLLM v1.94.2 Release, Release-Backport PR #36237 und Terraform-Provider PR #35844.