Three-Bug Chain Turns Any LiteLLM User Into Root on the AI Gateway
A default low-privilege account on the popular open-source LLM proxy can escalate to admin and execute code, exposing every provider key the gateway holds.

A default, low-privilege account on a LiteLLM proxy is enough to take over the server. Researchers at Obsidian Security chained three flaws to walk a basic user account up to administrator and then to remote code execution on the host.
That matters because LiteLLM isn't a niche tool.
The project ships an OpenAI-compatible gateway in front of more than 100 model providers — OpenAI, Anthropic, Bedrock, Azure, Vertex, and the long tail of self-hosted endpoints. Enterprises drop it in front of their LLM traffic to centralize billing, rate limits, and key storage. Which means the proxy is, by design, a vault of provider credentials.
A server takeover empties that vault.
What the chain looks like
The researchers describe a sequence that starts from the lowest-privilege role LiteLLM hands out by default. From there, two privilege issues let an attacker pivot to an admin role inside the proxy. A third bug converts admin access into code execution on the underlying host. End state: shell on the box, plus whatever provider API keys, database credentials, and environment secrets the proxy was configured with.
For most deployments, that includes production keys for at least one major model vendor. Some include cloud IAM credentials used to call Bedrock or Vertex.
Why this is worse than a key leak
A stolen OpenAI key is a billing problem. A compromised gateway is an interception problem. An attacker on the proxy sees prompt traffic, completions, and any data users piped through retrieval calls. That can include customer PII, source code, internal documents, and the contents of RAG pipelines — exactly the categories regulators have started asking pointed questions about.
In the U.S., the FTC has already signalled that mishandled AI-pipeline data falls under Section 5. In the EU, GDPR Article 33 notification clocks start when controllers know personal data was exposed, not when they finish investigating.
What operators should do now
- Pull LiteLLM upstream and rebuild. Track the project's release notes and the Obsidian writeup for the specific fixed version once disclosed.
- Rotate every provider key, database credential, and JWT signing secret the proxy touched. Assume disclosure.
- Audit user roles. Delete default low-privilege accounts that were created during setup and never removed.
- Put the proxy behind an authenticated ingress. A LiteLLM admin panel reachable from the public internet is, at this point, a configuration error.
If your gateway logs prompts or responses to disk or to a SIEM, review what categories of data were captured during the exposure window. Notification obligations attach to data, not to intent.



