CVE-2026-35029: LiteLLM Read-Only Keys Take Over the AI Gateway

LiteLLM sits in front of OpenAI, Anthropic, Azure OpenAI, Bedrock, Vertex, and local models. It holds provider API keys, virtual keys, spend records, and often the database URL for the control plane. That makes the admin API a high-value target. CVE-2026-35029 is a broken-access-control flaw in that control plane: POST /config/update did not enforce an admin role. Any authenticated caller, including a read-only key, could rewrite live proxy configuration.

GitHub advisory GHSA-53mr-6c8q-9789 rates it CVSS 8.7 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:N), CWE-863. Affected packages are LiteLLM before 1.83.0. The endpoint now requires proxy_admin. There is no configuration-only workaround.

This is not a theoretical finding. Zenity Labs honeypots recorded about 3,900 requests against LiteLLM admin routes from February through June 2026, across 73 source IPs. Roughly 1,000 of those hits targeted /config/update. The first probe arrived on 7 April 2026, one day after public disclosure on 6 April 2026. File-read payloads that match the published exploit chain showed up between 5 and 12 May 2026.

Root Cause

LiteLLM’s dashboard uses /config/update to change runtime settings, including environment_variables. Pre-1.83.0 code accepted that write from any authenticated principal. The product’s read-only role was supposed to observe, not mutate. The route did not check role.

Once an attacker can write config, three first-party features become primitives:

• UI_LOGO_PATH tells the dashboard which file to serve as the logo.
• GET /get_image reads that path and returns the bytes. It does not require authentication.
• UI_USERNAME and UI_PASSWORD control dashboard admin login.
• pass_through_endpoints can register custom proxy routes. The official advisory states those handlers can point at attacker-controlled Python and yield remote code execution.

Zenity reproduced the file-read and takeover chain on 1.74.0 with a read-only account, a mounted .env, and an attacker-controlled collector.

Exploit Path

Prerequisite: a valid LiteLLM API key that can reach the admin API. That is often a low-privilege or viewer key. Honeypot traffic also guessed default master keys (sk-1234, sk-litellm-master-key, sk-admin). If LITELLM_MASTER_KEY is unset, the proxy accepts unauthenticated admin calls. Internet-exposed gateways with those defaults are already past the "authenticated user" bar.

Arbitrary file read

1. Authenticate as the low-privilege user.
2. POST /config/update with a body such as {"environment_variables": {"UI_LOGO_PATH": "/app/.env"}}. Observed target paths also include /home/litellm/.env and /app/config.yaml.
3. GET /get_image with no auth header. The response is the file.

That file typically holds provider keys, LITELLM_MASTER_KEY, DATABASE_URL, cloud credentials, and observability secrets (including Langfuse keys when those are configured).

Dashboard takeover

The same write sets UI_USERNAME and UI_PASSWORD. The attacker logs into the UI as administrator and locks out the real operator.

Secret exfil via pass-through routes

An attacker registers a custom pass-through endpoint whose outbound headers resolve os.environ/... references. Triggering the route sends live environment values to an attacker-controlled host. This does not need /get_image and works even when logo serving is restricted.

RCE (advisory impact)

GHSA-53mr-6c8q-9789 lists a fourth path: register custom pass-through handlers backed by attacker-controlled Python. Treat any successful /config/update on an unpatched host as a potential code-execution event, not only a secret leak.

Scanning noise around the same window included JavaScript-style prototype pollution ({"__proto__": {"admin": true, "isAdmin": true}}). That payload is inert on the Python proxy. It is still a useful detection signature because it marks intent.

Why CISOs Should Care

LiteLLM is an AI supply-chain chokepoint. Compromise of the gateway is compromise of every downstream model key and of the prompt and spend data that flowed through it. A "read-only" integration key issued to a developer tool, a chatbot frontend, or a partner is enough. After exploitation, assume:

• Provider keys are burned. Attackers can call the same models off-platform, on the victim's bill.
• Virtual keys, team budgets, and model allowlists can be rewritten or deleted (/key/generate, /key/block, /model/delete, /user/new).
• The control-plane database is readable if DATABASE_URL leaked.
• Persistence can outlive a process restart if config or UI credentials were overwritten.

Rotate secrets after any exposure of a pre-1.83.0 admin API. Patching alone does not invalidate keys that already left the box.

MITRE ATT&CK Mapping

Patch and Hardening

• Upgrade LiteLLM to 1.83.0 or later. That release adds the proxy_admin check on /config/update (commit 57c05459ae9b4e607bfb35228ec13a3ee8586ce4).
• Do not treat 1.83.0 as the end of the story. Later 1.83.x and 1.84.0 releases address additional LiteLLM issues (key-generation route grants, user-role mass assignment, guardrail sandbox escape, MCP auth). If you are patching now, take the current stable line, not the first fixed tag for this single CVE.
• Set a strong, unique LITELLM_MASTER_KEY. Never ship sk-1234 or sk-litellm-master-key.
• Do not expose /config/update, /get_image, /key/generate, /user/new, /model/delete, or /scim/** to the public internet. Put the control plane behind SSO or an internal reverse proxy.
• Restrict who receives any LiteLLM virtual key. The vendor workaround is "restrict API key distribution." That is the only pre-patch control.
• If a pre-fix instance was reachable, rotate provider keys, the master key, DATABASE_URL credentials, cloud roles used by the proxy, and dashboard passwords. Review spend and model logs for minting of unexpected keys.

Detection

Alert on:

• POST /config/update bodies that set UI_LOGO_PATH to a filesystem path (/app/.env, /home/litellm/.env, /app/config.yaml, or any non-image path).
• GET /get_image immediately after a config write, especially with no session cookie.
• New pass_through_endpoints that embed os.environ/ in headers.
• Writes to UI_USERNAME or UI_PASSWORD outside a change window.
• Auth attempts using sk-1234, sk-litellm-master-key, sk-admin, or empty Authorization.
• Enumeration bursts against /key/info, /key/list, /user/info, /team/info, /global/spend, /scim/v2/*.

Indicators

IP hits on a honeypot are scanning evidence, not attribution. Use them as blocklist candidates and as hunt pivots, then confirm against your own proxy logs.

Bottom Line

CVE-2026-35029 collapses LiteLLM's role model. The dangerous object is not an unauthenticated RCE gadget on day zero. It is a viewer key plus one config write. Public exploit attempts started within 24 hours of disclosure. If your AI gateway is still below 1.83.0 and its admin API is reachable, treat it as compromised until logs, keys, and config say otherwise.

Sources

The intelligence provided in this report is derived from the following authoritative threat intelligence analysis:

• Zenity Labs: LiteLLM CVE-2026-35029: Exploited One Day After Disclosure

Hunt faster with the Threat Landscape Platform — premium threat intelligence, real-time IoC feeds, and an AI Assistant for instant answers. Professional starts at just $49/month.