An AI gateway like LiteLLM holds the keys to everything behind it: the API keys for every model provider, the database of users and spend, and the admin login itself. That makes it a high-value target, and not every account that can reach it is supposed to be able to change it.
Over February to June 2026, our honeypot sensors recorded ~3,900 requests against LiteLLM's admin API, including ~1,000 requests to the sensitive /config/update. Among these were the file-read exploit attempts that are signature of CVE-2026-35029, a broken-access-control flaw published on 2026-04-06 and fixed in LiteLLM 1.83.0. Attackers moved fast: the first /config/update attempts hit our sensors on 2026-04-07, the day after CVE was published.
LiteLLM's control plane as attack surface
LiteLLM has a "control plane": the administrative side of the gateway, made up of API routes that lets an admin mint API keys, set spending limits, manage models, and rewrite the proxy's configuration.
The /config/update endpoint
/config/update is the route the UI uses to change proxy settings, and can change the proxy’s live configuration, including environment variables LiteLLM reads sensitive secrets from. Also controlled is UI_LOGO_PATH, the file the server reads off disk to display the dashboard logo.
LiteLLM treats some config values as references rather than literals: a value like os.environ/OPENAI_API_KEY means "read the OPENAI_API_KEY environment variable and substitute its real value here," and a setting like UI_LOGO_PATH makes the server read the specific file path off the disk to display as the dashboard logo:
Both of these can become attacker primitives if a threat actor can access and overwrite the server’s configuration they can abuse these capabilities to achieve impact.
The authorization bypass: CVE-2026-35029
In a nutshell, CVE-2026-35029 is a missing authorization check on the /config/update endpoint. It lets a non-admin account change admin-only settings, meaning that LiteLLM's read-only role can call the config-editing route even though it should only be able to read it.
Once a read-only account can rewrite the server’s configuration, the attacker can chain various steps off it, such as:
- Arbitrary file read
Set UI_LOGO_PATH to a sensitive file path, then fetch it through the dashboard's logo-serving endpoint, /get_image. That endpoint requires no authentication at all, and the file content comes back using a plain GET request. - Credential exfiltration
Register a custom proxy route (LiteLLM calls these pass_through_endpoints, operator-defined URLs the gateway forwards elsewhere) whose outgoing headers contain os.environ/... references aimed at an attacker server. Triggering it exfiltrates the resolved secrets out. - Account takeover
Overwrite the dashboard login (UI_USERNAME / UI_PASSWORD), log in, and receive a full administrator session.
Design pattern exposure
Three design choices stack up to create the discussed bypass:
- LiteLLM’s config route (/config/update) doesn’t validate that the authenticated user is an admin.
- The proxy can read local files and resolve os.environ/VAR references on the server-side.
- The read endpoint /get_image requires no authentication as well, so the file an attacker configures as the UI_LOGO_PATH is retrievable by anyone who can reach the page where it’s displayed.
Suspicious activity breakdown
Across the mentioned time window we logged about 3.9K requests from 73 IP addresses against LiteLLM's admin routes.
Most notable types of activity
Keys guessing: carried no authentication or fuzzing default/placeholder master keys (sk-1234, sk-litellm-master-key, sk-admin, etc.), betting on proxies with no key set or a default left in place.
Targeted file-read exploitation: the actual CVE-2026-35029 payload: setting UI_LOGO_PATH to a secret file, then fetching it back through /get_image.
Prototype-pollution privilege escalation (a separate escalation attempt): /config/update bodies trying to set an admin flag through a polluted object prototype:
This is a JavaScript-style payload and is inert against LiteLLM's Python proxy, however it's a clear, deliberate escalation attempt rather than generic probing.
Minting credentials through /key/generate and /user/new. For example, we observed that this /user/new body attempts to create a brand-new administrator account outright:
If accepted, that hands the attacker a valid admin account on the proxy.
Enumeration of the deployment by reading keys, and users and more via /key/info, /key/list, /global/spend, /team/info, and /user/info
Destructive actions via /model/delete
Probed SCIM endpoints to map the user-provisioning surface: /scim/v2/ServiceProviderConfig, /scim/v2/Groups/1
The /config/update bodies
As explained earlier, we observed some of the requests setting UI_LOGO_PATH to a sensitive path so it can then be retrieved through /get_image. Here’s how the request bodies look like:
The attacker is guessing the likely locations of secrets across LiteLLM, for example:
- /app/.env, /home/litellm/.env (secret files)
- /app/config.yaml and similar (where API keys and the database URL variable reside)
These file-read payloads were sent between 2026-05-05 and 2026-05-12; however broader /config/update probing had begun earlier, on 2026-04-07, the day after the CVE was published.
Attack Reproduction
We observed the file-read exploitation from CVE-2026-35029, and wanted to reproduce based on what we observed (file read exploitation as seen above and in the disclosure) and what was possible (account takeover) as listed in the CVE’s advisory We reproduced the full attack chain on a real LiteLLM 1.74.0 (Postgres-backed, a sensitive .env mounted, an attacker-controlled collector) as an end-to-end verification. The first request, on the /config/update endpoint, rewrites config as a read-only user, which is the bug itself:
The second request, with no authentication, returns the contents of /app/.env exactly as written: with possible provider key, master key, AWS and Langfuse secrets.
One clarification on how attackers reach these (and other) admin API endpoints in the first place: LiteLLM only enforces authentication when a master key is configured. A proxy with no key accepts any request, and many that set one, leave it with the default value from the documentation. Strangely enough, in our capture, the traffic came overwhelmingly with no bearer values or with default master keys (e.g.., sk-1234, sk-litellm-master-key, etc.); we did not see low-privilege values in use.
Assessment
The traffic wasn't one undifferentiated scan: different source IPs concentrated on different parts of the admin API, some almost entirely on the /config/update file-read, others on key generation and fuzzing, others on destructive or provisioning calls like /model/delete and SCIM. The file read requests also carry the exact CVE-2026-35029 file-read technique, setting UI_LOGO_PATH to the specific paths where LiteLLM stores its secrets (.env, the config YAMLs, /proc/self/environ).
Cross-referencing these senders with VirusTotal explains this further:
- IPs in the file-read group (104.64.209.153 172.237.6.54, 216.26.226.182) are flagged as malicious by multiple vendors (GreyNoise, MalwareURL, SOCRadar)
- One enumerator (144.31.186.157) is marked as malicious/malware/phishing by 13 security vendors and suspicious by 2 of them.
- Most of the other heavy senders come back suspicious as well.
What to block
Abused endpoints
- /config/update
- /get_image
- /key/generate
- /key/block
- /scim/*
- /model/delete
Request-body signatures
- /config/update bodies that set UI_LOGO_PATH to a file path, e.g.
{"environment_variables": {"UI_LOGO_PATH": "/app/.env"}} - Prototype-pollution bodies, e.g.:
{"__proto__": {"admin": true, "isAdmin": true}}
Source IPs
- 104.64.209.153
- 172.237.6.54
- 216.26.226.182
- 154.219.123.193
- 173.249.198.201
- 108.78.4.10
- 164.52.192.134
- 89.117.53.228
- 95.164.235.177
- 144.31.186.157
- 107.148.181.88
- 125.81.162.148
- 193.34.72.43
- 141.148.228.249
- 52.195.13.67
Recommendations
- Upgrade to LiteLLM 1.83.0 or later. We confirmed the bypass is already rejected with a 403 on 1.81.0.
- Set up authentication, but never ship the example master key, and hand out the read-only role sparingly.
- Rotate LITELLM_MASTER_KEY off sk-1234 and any other default.
- Keep the control plane off the public internet. Put the Admin UI, /config/update, and /get_image behind an internal network or an authenticated proxy.
- Rotate all secrets if a pre-fix build was ever exposed. Assume the database connection string (DATABASE_URL), provider API keys, and Langfuse keys are compromised and rotate them, because those are exactly what this chain exfiltrates.
Why it matters
A low-privilege, read-only key should be the least dangerous credential in the system. On a vulnerable LiteLLM it is enough to take over the whole gateway. We verified the payoff in the lab: a handful of requests to /config/update was all it took to let a read-only account read any file on the server, exfiltrate the database connection string and provider keys, and log in as a full administrator while locking the real one out.
The timing is also part of why this matters. CVE-2026-35029 was published on 2026-04-06, and the first /config/update request hit our sensors on 2026-04-07: a one-day gap between public disclosure and live exploitation attempts, with the detailed file-read payloads following a few weeks later.