Den Einstieg bildet CVE-2026-47101, ein Umgehen von Autorisierungsprüfungen. Erzeugt ein normaler Benutzer, in LiteLLM als internal_user bezeichnet, einen virtuellen API-Schlüssel, speichert die Software das vom Aufrufer gesetzte Feld allowed_routes, ohne es gegen die Rolle des Nutzers zu prüfen. Eigentlich soll dieses Feld die Möglichkeiten eines Schlüssels einschränken. Laut Obsidian behandelt der Proxy es jedoch zugleich als Ersatzberechtigung. Dadurch kann ein Nicht-Administrator einen Schlüssel mit allowed_routes: ["/*"] erzeugen und so sämtliche Routen erreichen, einschließlich solcher, die nur für Administratoren vorgesehen sind. Dieselbe ungeprüfte Schreibmöglichkeit taucht laut Bericht auch in weiteren Endpunkten zur Schlüsselverwaltung auf; deshalb waren drei Pull Requests nötig, um den Fehler vollständig zu beheben.
Ist diese Routensperre ausgehebelt, werden dahinterliegende Handler erreichbar, die laut Obsidian voraussetzen, dass die Prüfung bereits erfolgt ist. Daraus ergeben sich zwei weitere Angriffswege. Der erste ist CVE-2026-47102, eine Rechteausweitung. Der Endpunkt /user/update erlaubt es Nutzern, ihren eigenen Datensatz zu ändern, begrenzt aber nicht, welche Felder sie schreiben dürfen. Ein Selbst-Update mit user_role: “proxy_admin” wird akzeptiert und gespeichert. Damit steigt der Aufrufer zum vollständigen Proxy-Administrator auf. VulnCheck, das die CVE vergeben hat, bewertet die Schwachstelle 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. Diese kompiliert und startet von Administratoren gelieferten Python-Code. Auf den Produktionsendpunkten wurde der Code laut Obsidian über exec() ausgeführt, ohne Filterung auf Quelltextebene. Wenn exec() ein globals-Dictionary ohne builtins erhält, ergänzt Python stillschweigend das vollständige builtins-Modul. Damit stehen dem Code unter anderem import, open und eval zur Verfügung. Ein einfacher Aufruf von os.system reichte anschließend für eine Reverse Shell. Einen separaten Pfad im Spielplatz-Endpunkt /guardrails/test_custom_code entdeckte X41 D-Sec unabhängig davon: Dort ließ sich eine Regex-Sperrliste durch Umschreiben von Bytecode zur Laufzeit umgehen. Beide Wege endeten in serverseitiger Codeausführung.
Welche Reichweite das hat, ergibt sich aus der Rolle von LiteLLM als Vermittler. Eine vollständige Kette legt laut Obsidian den Master Key, den Salt Key zum Entschlüsseln gespeicherter Zugangsdaten und die Datenbank-URL offen. Betroffen sind außerdem 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 verschlüsselt, lassen sich mit dem Salt Key aber wiederherstellen. Lesbar werden außerdem sämtliche Prompts und Antworten, die das Gateway durchlaufen. Wenn der Proxy zusätzlich als Model Context Protocol (MCP)- oder Agent-Gateway betrieben wird, fallen auch OAuth-Tokens und Werkzeug-Zugangsdaten in den möglichen Zugriffsumfang.
Obsidian betont allerdings, dass die größere Gefahr nicht nur im Mitlesen liegt, sondern im Umschreiben. Da das Gateway zwischen KI-Agent und Modell sitzt, kann ein Angreifer Antworten unterwegs verändern. Gezeigt wurde das gegen Claude Code, das über einen kompromittierten Proxy lief. Dabei handelte es sich laut Obsidian nicht um Prompt Injection. Statt das Modell zu Fehlverhalten zu bewegen, nutzte der Angreifer LiteLLMs eingebauten Callback-Mechanismus, der bei jeder Anfrage ausgelöst wird und in der Admin-Oberfläche nicht erscheint. Der Callback ersetzte die Modellantwort durch einen gefälschten Werkzeugaufruf und schrieb den Kontext der Sicherheitsprüfung so um, dass die Aktion als genehmigt erschien. In der Demonstration tippte der Entwickler nur das Wort „Hallo“, worauf auf dessen Rechner eine Reverse Shell gestartet wurde.
Separat von dieser Kette gibt LiteLLM einem proxy_admin bereits absichtlich einen Weg zur Codeausführung: Über die MCP-Unterstützung kann ein Administrator stdio-MCP-Server registrieren, die der Proxy als lokale Unterprozesse startet. Laut Bericht ist das eine Designentscheidung und kein Fehler; die Patches ändern daran nichts. Wer also Admin-Rechte erreicht, erreicht faktisch auch Codeausführung. Obsidian reproduzierte auf diesem Weg eine Reverse Shell auf v1.88.0. Hinzu kommt mit CVE-2026-42271 ein echter Fehler in derselben stdio-MCP-Mechanik: Darüber konnten Aufrufer über LiteLLMs MCP-Vorschau-Endpunkte Unterprozesse starten. Diese Schwachstelle wurde bereits aktiv ausgenutzt und in diesem Monat in CISAs KEV-Katalog aufgenommen.
Obsidian beschreibt die nun offengelegte Kette als gemeldeten Fehler mit funktionierendem Demonstrator, nicht als bereits beobachtete Ausnutzung in freier Wildbahn. BerriAI hat die vollständigen Korrekturen in LiteLLM v1.83.14-stable integriert. Zusätzlich empfiehlt Obsidian, alle Konten mit proxy_admin erneut zu prüfen, jede Custom Code Guardrail auf dem Proxy zu kontrollieren und insbesondere die aus config.yaml unter litellm_settings.callbacks geladenen Callbacks zu untersuchen, weil sie nicht in der Konsole erscheinen. Bei vermuteter Gefährdung sollen Provider-Schlüssel, Datenbank-Zugangsdaten und gespeicherte MCP-Tokens rotiert werden.