URL-Routing im AI-Gateway: Warum Provider-Keys nicht mitdürfen

LiteLLM 1.95.0 behebt ein sicherheitsrelevantes Routing-Problem: Bei URL-basierten Modelldestinationen und Fallbacks sollen Provider-Credentials nicht mehr potenziell an ein Ziel weitergereicht werden, das über eine URL konfiguriert ist. Die Release Notes nennen den Fix ausdrücklich, liefern aber weder CVE noch Angaben zu aktiver Ausnutzung.

Warum das im Gateway wichtig ist

Ein AI-Gateway besitzt oft langlaufende Zugangsdaten für OpenAI, Anthropic, Bedrock oder andere Provider. Routing-Konfiguration ist dagegen näher an Anwendung und Betrieb: Modelle, Fallbacks und Zieladressen ändern sich häufiger. Werden beide Ebenen unsauber gekoppelt, wird eine URL-Konfiguration plötzlich zur Credential-Grenze.

Der entscheidende Architekturgrundsatz ist banal, aber nicht optional: Ein Routenziel bestimmt, wohin eine Anfrage geht – nicht, welche Provider-Identität es erhält. LiteLLM 1.95.0 zieht diese Grenze für URL-wertige Modelldestinationen und Fallbacks nach.

Was Betreiber jetzt prüfen sollten

• LiteLLM-Proxies auf v1.95.0 oder eine nachfolgende Release-Version aktualisieren.
• Konfigurationen nach URL-basierten model-Zielen, Custom Destinations und Fallbacks durchsuchen.
• Provider-Schlüssel auf kleinste nötige Rechte und getrennte Projekte/Konten begrenzen.
• Proxy- und Egress-Logs darauf prüfen, ob Credentials oder Authorization-Header an unerwartete Hosts gelangten.

Der Patch ist kein Anlass, jedes URL-Routing abzuschalten. Er ist ein Anlass, Routing-Daten und Credential-Custody als zwei getrennte Kontrollflächen zu behandeln.

Einordnung

Der Fix kommt in einem umfangreichen Release mit MCP-, Routing- und Gateway-Arbeit. Für den Betrieb ist genau dieser unscheinbare Sicherheitsfix relevanter als viele Feature-Zeilen: AI-Gateways zentralisieren Credentials. Damit wird jede dynamische Zielauflösung zu einem Security-Review-Punkt.

Quelle: LiteLLM v1.95.0 – offizielle Release Notes (veröffentlicht am 3. August 2026). Die Release Notes dokumentieren: „Prevent potential provider key exposure through URL-valued model destinations and fallbacks.“