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.
Key points
- Obsidian Security chained three vulnerabilities to move from a default low-privilege LiteLLM account to full admin, then to remote code execution on the host.
- LiteLLM brokers calls to more than 100 model providers behind a single OpenAI-compatible interface, making it a credential vault by design.
- A successful takeover exposes every provider API key, database credential, and environment secret the proxy holds.
- Prompt traffic, completions, and retrieval pipeline data are readable to an attacker on the box, including anything users sent through it.
- Operators should rotate all secrets immediately and audit user roles, not wait for a patched release.
What the chain looks like
The attack starts from the lowest-privilege role LiteLLM assigns by default. Two privilege issues let an attacker climb to admin inside the proxy. A third converts that admin access into code execution on the underlying host. End state: a shell on the box, plus every secret the proxy was configured with.
For most deployments that includes production keys for at least one major model vendor. Some hold cloud IAM credentials used to reach hosted model services.
We covered a related LiteLLM flaw on 9 June when CVE-2026-42271 hit the CISA Known Exploited Vulnerabilities catalogue, with active exploitation already confirmed. This disclosure shows the attack surface is wider than that single CVE.
Why this is worse than a key leak
A stolen API key is a billing problem. A compromised gateway is an interception problem. An attacker sitting on the proxy sees everything passing through it: prompt content, model responses, retrieval calls that may carry customer records or internal documents. Those are precisely the data categories regulators have begun asking pointed questions about.
In the U.S., the FTC has signalled that mishandled AI-pipeline data falls under Section 5. EU data protection law requires controllers to notify authorities once they know personal data was exposed, not after they finish investigating.
Should you worry?
If you run a self-hosted LiteLLM instance, yes. The question is whether your deployment has default low-privilege accounts still active from setup, and whether the admin panel is reachable without additional authentication. Both are common in internal deployments that were stood up quickly and never hardened.
LiteLLM's positioning as a central broker is exactly what makes this sting: one compromised instance can expose credentials for every model provider the organisation uses.
What operators should do now
- Pull the latest LiteLLM release and track the Obsidian writeup for the specific fixed version once disclosed.
- Rotate every provider key, database credential, and JWT signing secret the proxy touched. Treat them as compromised.
- Delete default low-privilege accounts created during setup and never removed.
- Put the proxy behind authenticated ingress. An admin panel reachable from the public internet is a configuration error at this point.
If your gateway logs prompts or responses, review what data categories were captured during any exposure window. Notification obligations attach to the data, not to intent.
