LiteLLM proxy config endpoint let any authenticated user reach remote code execution

Undisclosed (self-hosted LiteLLM proxy operators)·LiteLLM AI Gateway/Proxy (PyPI package litellm)Fixed

LiteLLM's /config/update endpoint did not enforce admin-role authorization, so any already-authenticated user could rewrite proxy configuration and environment variables, register a custom pass-through endpoint pointing at attacker-controlled Python code to get remote code execution, read arbitrary server files by setting UI_LOGO_PATH and fetching it via /get_image, and overwrite UI_USERNAME/UI_PASSWORD to take over the admin account. It was disclosed alongside five related advisories in the same LiteLLM batch: self-role-escalation via /user/update, creation of over-privileged API keys by internal users, authenticated command execution via MCP stdio test endpoints, a sandbox escape in the custom-code guardrail feature, and server-side template injection in /prompts/test.

Blast radius

Not disclosed as exploited in the wild; the flaw affected all versions of the litellm PyPI package prior to 1.83.0 (CVSS 4.0 8.7/High), meaning every self-hosted LiteLLM proxy deployment that let non-admin users authenticate was exposed to full server compromise, credential/config theft and admin takeover until patched.

Root cause

Missing server-side role checks on multiple 'admin-only' proxy management endpoints (config update, user-role update, key creation, MCP test routes, guardrail sandboxing, prompt templating), so authorization relied on the client never calling them rather than being enforced by the server.

How it was caught

Found and responsibly disclosed as a security advisory (GHSA-53mr-6c8q-9789 / CVE-2026-35029) rather than caught via a production breach; no in-the-wild exploitation is documented in the source.

What changed

Patched in litellm v1.83.0: /config/update now requires the proxy_admin role; no configuration-level workaround existed before the patch.

Take-awayOn an AI gateway, every endpoint that can change config, roles, API-key scope, or execute code/tools (including MCP and guardrail sandboxes) needs its own explicit server-side authorization check — don't assume UI-level restrictions are enough.