Den Einstieg bildet CVE-2026-47101, ein Umgehen der Autorisierung. Erzeugt ein normaler Nutzer mit der Rolle internal_user einen virtuellen API-Schlüssel, speichert LiteLLM das vom Aufrufer gesetzte Feld allowed_routes, ohne es gegen die Benutzerrolle zu prüfen. Dieses Feld soll den Aktionsradius eines Schlüssels eigentlich einschränken. Laut Obsidian behandelt der Proxy es aber zugleich als Fallback-Berechtigung. Dadurch kann ein Nicht-Administrator einen Schlüssel mit allowed_routes: ["/*"] erzeugen und so sämtliche Routen erreichen, auch solche, die nur für Administratoren vorgesehen sind. Derselbe ungeprüfte Schreibvorgang taucht den Forschern zufolge auch an weiteren Endpunkten der Schlüsselverwaltung auf; deshalb waren drei Pull Requests nötig, um den Fehler vollständig zu beheben.
Ist diese Routenprüfung ausgehebelt, werden dahinterliegende Handler erreichbar, die sich darauf verlassen, dass die Zugriffskontrolle bereits anderswo erfolgt ist. Daraus ergeben sich zwei weitere Wege. Der erste ist CVE-2026-47102, eine Privilegienausweitung. Der Endpunkt /user/update erlaubt es Nutzern, ihren eigenen Datensatz zu ändern, beschränkt 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. VulnCheck, das die CVE vergeben hat, bewertet die Schwachstelle mit 8,7 nach CVSS 4.0 und 8,8 nach CVSS 3.1. Ein org_admin kann diesen Endpunkt laut Quelle auf legitimen, vorgesehenen Wegen erreichen; ein standardmäßiger internal_user erst nach Ausnutzung von CVE-2026-47101.
Der zweite Pfad ist CVE-2026-40217, ein Ausbruch aus der Sandbox in der Funktion Custom Code Guardrail, die von Administratoren gelieferten Python-Code kompiliert und ausführt. Auf den Produktionsendpunkten wurde der Code laut Obsidian per exec() ausgeführt, ohne Filterung auf Quelltextebene. Bekommt exec() ein globals-Wörterbuch ohne builtins, fügt Python stillschweigend das vollständige builtins-Modul ein. Dadurch stehen dem Code unter anderem import, open und eval zur Verfügung. Ein einfacher Aufruf von os.system reichte den Forschern dann für eine Reverse Shell. Einen separaten Weg auf dem Playground-Endpunkt /guardrails/test_custom_code fand X41 D-Sec unabhängig: Dort ließ sich eine Regex-Sperrliste durch Umschreiben von Bytecode zur Laufzeit umgehen. Beide Varianten endeten in serverseitiger Codeausführung.
Die Folgen einer Übernahme sind weitreichend, weil LiteLLM als Knotenpunkt fungiert. Laut Obsidian werden bei einer vollständigen Kette der Master Key, der Salt Key zum Entschlüsseln gespeicherter Zugangsdaten und die Datenbank-URL offengelegt. Hinzu kommen alle konfigurierten Provider-Schlüssel, etwa für OpenAI, Anthropic, Gemini, Bedrock und Azure. Schlüssel in Konfiguration oder Umgebung liegen im Klartext vor; Schlüssel in der Datenbank sind zwar verschlüsselt, aber mit dem Salt Key wiederherstellbar. Lesbar wird außerdem sämtlicher Verkehr durch das Gateway, also Prompts und Antworten. Läuft der Proxy zusätzlich als Gateway für Model Context Protocol oder Agenten, fallen auch OAuth-Tokens und Tool-Zugangsdaten in den Wirkungsbereich.
Obsidian hebt aber hervor, dass die größere Gefahr nicht nur im Mitlesen liegt, sondern im Umschreiben. Das Gateway sitzt zwischen KI-Agent und Modell; ein kompromittierter Proxy kann daher Antworten während der Übertragung verändern. Demonstriert wurde das gegen Claude Code, das über einen kompromittierten Proxy geroutet wurde. Laut Obsidian handelt es sich dabei nicht um Prompt Injection. Statt das Modell zu einem Fehlverhalten zu verleiten, missbraucht der Angreifer den eingebauten Callback-Mechanismus von LiteLLM, der bei jeder Anfrage ausgelöst wird und in der Administrationsoberfläche nicht erscheint. In der Demo ersetzt der Callback die Modellantwort durch einen gefälschten Tool-Aufruf und schreibt den Kontext der Sicherheitsprüfung so um, dass die Aktion als genehmigt erscheint. Im gezeigten Szenario tippt der Entwickler nur das Wort „Hallo“, worauf auf seinem Rechner eine Reverse Shell geöffnet wird.
Unabhängig von dieser Kette besitzt LiteLLM für proxy_admin bereits absichtlich einen Weg zur Codeausführung: Über die MCP-Unterstützung können Administratoren stdio-MCP-Server registrieren, die der Proxy als lokale Subprozesse startet. Der Bericht beschreibt das als Entwurfsentscheidung, nicht als Fehler; die Patches ändern daran nichts. Wer also Administratorrechte erreicht, erreicht praktisch auch Codeausführung. Obsidian reproduzierte auf diesem Weg eine Reverse Shell auf v1.88.0. Ein echter Fehler in derselben stdio-MCP-Mechanik, CVE-2026-42271, erlaubte es Aufrufern, über LiteLLMs MCP-Vorschauendpunkte Subprozesse zu starten. Diese Schwachstelle wurde laut Quelle bereits aktiv ausgenutzt und in diesem Monat in CISA’s KEV-Katalog aufgenommen.
Obsidian beschreibt die jetzt veröffentlichte Kette als offengelegte Schwachstelle mit funktionsfähiger Demonstration, nicht als bereits in freier Wildbahn beobachtete Ausnutzung. Als Abhilfe nennt der Bericht ein Upgrade auf LiteLLM v1.83.14-stable oder neuer, da diese Version den vollständigen Fix-Satz enthält. Zudem sollten alle Konten mit proxy_admin erneut überprüft, alle Custom Code Guardrails auf dem Proxy kontrolliert und die in config.yaml unter litellm_settings.callbacks geladenen Callbacks geprüft werden, weil sie nicht in der Konsole erscheinen und sich dort ein Angreifer nach einer Codeausführung verbergen könnte. Bei Verdacht auf Exposition sollten Provider-Schlüssel, Datenbank-Zugangsdaten und gespeicherte MCP-Tokens rotiert werden.