Developer Tools

One proxy, every model key: what the LiteLLM takeover bug really exposes

A chained LiteLLM flaw let a low-privilege user reach admin and run code on the gateway. The real exposure is what an AI proxy concentrates in one place.

One proxy, every model key: what the LiteLLM takeover bug really exposes editorial image

An AI gateway is meant to be the dull, dependable part of the stack. You stand LiteLLM or a tool like it in front of your applications, point everything at a single endpoint, and let it route requests out to Anthropic, OpenAI, Google, and whatever else is on the invoice that month. The draw is operational tidiness: a single place to rotate keys, cap spend, and see who is calling what. The cost of that tidiness is concentration, and concentration is easy to forget about until someone shows you the blast radius. On June 11, Obsidian Security did exactly that.

Obsidian's researchers disclosed a chain of three vulnerabilities in LiteLLM, the widely deployed open-source proxy that brokers calls to more than a hundred model providers. Chained together they rate a CVSS score of 9.9, a hair short of the maximum, and the severity is all in the path they open: a default, low-privilege user on the proxy can climb to full administrator and then execute arbitrary code on the host. What should unsettle anyone running this kind of infrastructure is how unremarkable each step is. These are ordinary authorization mistakes — the kind that predate AI gateways entirely.

Three ordinary bugs, one full takeover

Walk the chain in order. The first flaw, CVE-2026-47101, is an authorization bypass: LiteLLM's key-management routes, such as /key/generate and /key/update, accepted an allowed_routes field without confirming the caller was allowed to set it, so a non-admin could mint itself a key scoped to routes it had no business touching, admin-only ones included. The second, CVE-2026-47102, is blunter — the /user/update and /user/bulk_update endpoints left the user_role field unprotected from the caller, which means a user could edit their own role and hand themselves proxy_admin. The third, CVE-2026-40217, converts that stolen authority into code on the box: LiteLLM's custom-code guardrail ran user-supplied code through Python's exec() with __builtins__ still in reach, and the regex meant to fence it in could be walked past with bytecode tricks. (X41 D-Sec independently reported that regex-bypass variant.)

Strung together, the story is a low-privilege account minting an over-scoped key, promoting itself to admin, and then escaping a guardrail that was supposed to be a safety feature. Every link is a check that was never written: field-level authorization that nobody enforced, and an exec() call trusting input that should never have been trusted in the first place.

The patch is the easy part

Apply the fix, and do it without ceremony. All three issues are closed in v1.83.14-stable, which BerriAI shipped on April 25 after Obsidian's February report, so upgrading to that release or later closes the chain. LiteLLM is usually something you run yourself, so this is a patch you apply; if you reach it through a managed or vendor-hosted offering, confirm with that provider that the fix is already in place — the target is v1.83.14-stable or later. Obsidian only made the writeup public on June 11, and as of mid-June there is no confirmed account of the chain being exploited in the wild. That last fact is the one most likely to be misread. A quiet few weeks since the patch tells you nothing about the question that actually matters here: what would have been reachable if someone had gotten there first.

This is where a gateway's selling point turns on it. A proxy that fronts a hundred providers is, by construction, the place where the keys for every provider it brokers can be decrypted — and the credentials that decrypt them sit there too. Take over the host and you do not get one team's OpenAI key; you get all of them, plus the spend controls and routing the gateway manages, and code execution on the machine that brokered everything. The same setup that makes a gateway convenient to operate is what turns it into a single, very high-value target.

So the judgment is straightforward, even if acting on it is not. An AI gateway is not plumbing; it is a secrets store with a routing feature bolted on, and it deserves the blast-radius assumptions you would give a vault. In practice that means isolating it on the network, enforcing least privilege rather than assuming it so that no default account sits one unchecked field-write from administrator, and staying genuinely wary of any feature built to execute the input it receives. Patching these particular endpoints closes this particular chain. The lesson behind it is bigger than LiteLLM, and that is the part worth keeping once the CVE numbers are forgotten.

An old bug class wearing new clothes

The AI infrastructure layer is young and building at speed, and it keeps rediscovering web-application security the hard way. It is not the only recent example. The same stretch of the calendar brought a package-registry worm that harvested CI and cloud secrets the moment a poisoned dependency installed — a different target, the same underlying shapes: injection, missing authorization, untrusted input handed to an interpreter. Across these stories the genuinely new part is the context, and the value of what gets pooled behind it. The bug classes are the ones in every security textbook.

That reframing is the practical takeaway, because it tells you how to treat these systems. The parts of your stack that talk to models are ordinary attacker-facing software that happens to hold unusually valuable secrets, and they deserve the scrutiny any service in that position would get: patched promptly, isolated on the network, and locked down even when locking them down is inconvenient. If you would rather not pool every key in one place to begin with, that is a legitimate design answer too; running smaller models locally keeps some workloads off the shared gateway entirely.

The LiteLLM chain will be patched and forgotten well before the pattern it illustrates is. The question worth carrying out of it is simpler than any CVE: whether the box that holds all your model keys is being guarded like the most valuable thing you run — because to whoever finds the next authorization gap, that is exactly what it is.

Source links