Den Einstieg bildet laut Obsidian Security CVE-2026-47101, ein Autorisierungs-Bypass. Wenn ein regulärer Nutzer mit der Rolle internal_user einen virtuellen API-Schlüssel erzeugt, speichert LiteLLM das vom Aufrufer gesetzte Feld allowed_routes, ohne es gegen die Rolle des Nutzers zu prüfen. Dieses Feld soll eigentlich einschränken, was ein Schlüssel darf. Tatsächlich behandelt der Proxy es aber auch als eine Art Ersatzberechtigung. Dadurch kann ein Nicht-Admin einen Schlüssel mit allowed_routes: ["/*"] erzeugen und so alle Routen erreichen, auch solche, die nur für Administratoren gedacht sind.
Weil sich derselbe ungeprüfte Schreibzugriff auch an weiteren Endpunkten zur Schlüsselverwaltung findet, waren laut Quelle drei Pull Requests nötig, um die Lücke vollständig zu schließen. Ist die Routenprüfung einmal umgangen, werden dahinterliegende Handler erreichbar, die voraussetzen, dass die Zugriffskontrolle bereits zuvor sauber erfolgt ist. Genau daraus ergeben sich die nächsten beiden Angriffswege.
Der erste ist CVE-2026-47102, eine Rechteausweitung. Der Endpunkt /user/update erlaubt es Nutzern, ihren eigenen Datensatz zu verändern, begrenzt aber nicht, welche Felder sie schreiben dürfen. Ein Selbst-Update mit user_role: “proxy_admin” wird akzeptiert und gespeichert. Damit wird der Aufrufer zum vollständigen Proxy-Administrator. Ein org_admin kann diesen Pfad laut Quelle ohnehin auf legitime Weise nutzen; ein standardmäßiger internal_user erreicht ihn erst nach Ausnutzung von CVE-2026-47101. VulnCheck, das die CVE vergeben hat, bewertet die Lücke mit 8.7 nach CVSS 4.0 und 8.8 nach CVSS 3.1.
Der zweite Weg ist CVE-2026-40217, ein Ausbruch aus der Sandbox in der Funktion Custom Code Guardrail. Dort kompiliert und startet LiteLLM von Administratoren bereitgestellten Python-Code. Nach Darstellung von Obsidian liefen die Produktionsendpunkte über exec() ohne Filterung des Quelltexts. Wenn exec() ein globals-Dictionary ohne builtins erhält, fügt Python stillschweigend das vollständige builtins-Modul ein. Dadurch stehen dem ausgeführten Code unter anderem import, open und eval zur Verfügung. Ein einfacher Aufruf von os.system reichte dann für eine Reverse Shell.
Einen separaten Pfad am Playground-Endpunkt /guardrails/test_custom_code fand X41 D-Sec unabhängig davon. Dort ließ sich eine auf regulären Ausdrücken basierende Sperrliste durch Umschreiben des Bytecodes zur Laufzeit umgehen. Beide Wege endeten laut Quelle in serverseitiger Codeausführung.
Die Folgen einer Übernahme sind bei LiteLLM besonders gravierend, weil das System an einer zentralen Stelle sitzt. Eine vollständige Ausnutzung legt den Master Key, den Salt Key zur Entschlüsselung gespeicherter Zugangsdaten und die Datenbank-URL offen. Zudem werden alle konfigurierten Provider-Schlüssel sichtbar, darunter für OpenAI, Anthropic, Gemini, Bedrock und Azure. Schlüssel in Konfiguration oder Umgebung liegen im Klartext vor; in der Datenbank gespeicherte Schlüssel sind zwar verschlüsselt, lassen sich mit dem Salt Key aber wiederherstellen.
Hinzu kommt das eigentliche Verkehrsaufkommen des Gateways. Alles, was durch LiteLLM läuft, also Prompts und Antworten, kann mitgelesen werden. Obsidian betont aber, dass das größere Risiko nicht im Lesen, sondern im Manipulieren liegt. Da das Gateway zwischen KI-Agent und Modell sitzt, kann ein Angreifer Antworten auf dem Transportweg verändern. Die Forscher demonstrierten das gegen Claude Code hinter einem kompromittierten Proxy. Über LiteLLMs eingebauten Callback-Mechanismus, der bei jeder Anfrage auslöst und in der Admin-Oberfläche nicht erscheint, wurde die Modellantwort durch einen gefälschten Tool-Aufruf ersetzt und zugleich der Kontext der Sicherheitsprüfung so umgeschrieben, dass die Aktion als genehmigt erschien. In der Demo tippte der Entwickler nur das Wort „Hallo“, worauf auf dessen Rechner eine Reverse Shell gestartet wurde.
Unabhängig von dieser Kette weist der Bericht noch auf einen absichtlich vorhandenen Weg zur Codeausführung für proxy_admin hin: Über die MCP-Unterstützung kann ein Administrator stdio-MCP-Server registrieren, die der Proxy als lokale Subprozesse startet. Obsidian wertet das als Designentscheidung, nicht als Fehler; die Patches ändern daran nichts. Wer also Admin-Rechte erreicht, erreicht damit praktisch auch Codeausführung. Obsidian konnte auf v1.88.0 auf diesem Weg ebenfalls eine Reverse Shell reproduzieren. Daneben gab es mit CVE-2026-42271 einen echten Fehler in derselben stdio-MCP-Mechanik: Über LiteLLMs MCP-Vorschau-Endpunkte konnten Aufrufer Subprozesse starten. Diese Schwachstelle wurde nach Angaben der Quelle bereits aktiv ausgenutzt und in diesem Monat in den KEV-Katalog von CISA aufgenommen.
LiteLLM war in diesem Jahr bereits mehrfach Ziel ernster Sicherheitsvorfälle. Im März wurden laut Quelle zwei LiteLLM-Versionen auf PyPI durch eine Supply-Chain-Kompromittierung mit einer Hintertür versehen. Im April wurde zudem eine kritische SQL-Injection binnen 36 Stunden nach ihrer Offenlegung ausgenutzt. Die nun von Obsidian beschriebene Kette wird als offengelegte Schwachstelle mit funktionierendem Demonstrationsangriff eingeordnet, nicht als bereits beobachtete Ausnutzung unter realen Angreifern.