On Monday, researchers at Obsidian Security published a detailed breakdown of how to take any LiteLLM account from basic user to full server admin — and then run arbitrary code on the machine — in three steps. The combined severity is CVSS 9.9. The fix has been available since early May. Most self-hosted deployments haven't applied it.
If you're running a self-hosted LiteLLM proxy as your AI API gateway, you need to read this.
What LiteLLM is and who uses it
LiteLLM is the open-source library that turns a single API endpoint into a router for every major AI provider — OpenAI, Gemini, Cohere, Bedrock, Azure, Mistral, and about 140 others. You point your applications at one LiteLLM proxy, and it handles routing, cost tracking, rate limits, and access control across all your AI APIs.
For a 15-person team juggling multiple AI tools, this is genuinely useful. One place to rotate keys. One dashboard to see what's spending money. One layer to enforce which team members can call which models. It's become one of the most widely deployed pieces of AI infrastructure for teams that aren't large enough to build their own API management layer.
That's also what makes this week's disclosure significant.
The three bugs, explained plainly
Obsidian Security's researchers chained three separate vulnerabilities together:
CVE-2026-47101 (Authorization bypass): When any authenticated user generates a virtual API key through LiteLLM's /key/generate endpoint, the allowed_routes parameter — which controls what API paths that key can reach — gets stored exactly as submitted. No validation against what your role actually permits. A standard internal_user account can create a key with allowed_routes: ["/*"], a wildcard that reaches every API endpoint in the system, including admin-only ones. You didn't need to be an admin to do this. You just needed to be any user with a key.
CVE-2026-47102 (Privilege escalation): Once you have a wildcard key from the first bug, the /user/update endpoint becomes reachable. This endpoint lets users modify their own account details. The problem: user_role is one of the modifiable fields, and the API doesn't check whether the caller is allowed to change it. A regular user can send a POST request updating their own role to proxy_admin. Done. You're now an admin on a server you had no business administering.
CVE-2026-40217 (Code execution): LiteLLM includes a feature called Custom Code Guardrails that lets admins write Python callbacks to inspect or filter model requests. Under the hood, it compiles and executes that code via Python's exec(). No sandbox. No source filtering. As an admin — which you just became — you can push a guardrail payload that runs whatever you want on the server.
Three steps. Any user account. Full code execution.
The no-credentials version
If the LiteLLM server is using Starlette 1.0.0 or below as its ASGI framework — which many installations still are — there's an additional path involving CVE-2026-48710, a Host header validation bypass in Starlette itself. That vulnerability lets an attacker skip LiteLLM's authentication layer entirely, turning this from a "low-privilege user exploit" into a "no credentials needed at all" exploit. If your LiteLLM instance is reachable from the internet, that version of the chain requires nothing except a network connection.
Why this matters for your team
You might be thinking: "we trust everyone who has a LiteLLM account." Maybe you do. But LiteLLM proxy deployments tend to give out keys fairly liberally — to contractors, to developers, to automated pipelines. The threat model here isn't a disgruntled insider. It's a scenario where any of those accounts gets compromised (phished, credential-stuffed, leaked in a paste), and an attacker uses that low-value token as a stepping stone to root on your AI infrastructure server.
That server is typically the one holding your OpenAI API key, your Anthropic key, your Gemini key. The one with access to your vector database. The one logging every prompt your team has sent to any model. In a lot of small-org deployments, it's running on a machine that can also reach internal databases or internal services because it was set up quickly and the network segmentation was never a priority.
An attacker with code execution on that machine doesn't just get your AI API keys. They get everything those keys can touch.
This isn't a theoretical concern. A separate LiteLLM command injection vulnerability (CVE-2026-42271) was added to CISA's Known Exploited Vulnerabilities catalog on June 8 — meaning there is active, real-world exploitation of LiteLLM infrastructure happening right now. That CVE is different from Monday's disclosure, but it confirms that attackers have already identified LiteLLM deployments as targets worth hitting.
What to do right now
Check your LiteLLM version. The fixes are in v1.83.14-stable. Run pip show litellm in your environment, or check your Docker image tag. If you're below that version, you're vulnerable.
Update immediately. pip install --upgrade litellm for Python installs. Pull and redeploy the ghcr.io/berriai/litellm:main-stable image if you're running Docker. The maintainers at BerriAI moved quickly on this — the complete fix set landed in mid-April. The 6-week gap since then is the window you're closing by updating today.
Check your Starlette version. If your deployment uses Starlette at or below 1.0.0, update that too. The fix for CVE-2026-48710 is in Starlette 1.0.1.
Rotate your API keys. If you've been running a vulnerable version in an environment where multiple people or services hold LiteLLM user credentials, treat your upstream provider API keys as potentially compromised. Rotate them as a precaution. This is fast and low-cost insurance.
Audit who has user accounts. If you've handed out LiteLLM API keys to contractors, to demo users, to pipelines you stood up six months ago, now is a good time to enumerate what's active and revoke anything you don't recognize or no longer need.
Check internet exposure. If your LiteLLM proxy is accessible from the public internet rather than restricted to internal networks or VPN, move it behind a network boundary. None of these exploits require physical access — they work over the network.
The pattern here
This is the third significant LiteLLM security incident this year. In April, the supply chain attack on the PyPI package compromised installations via malicious code injected into the library itself. In June, CVE-2026-42271 (already actively exploited) hit the MCP server endpoints. Now this privilege escalation chain.
LiteLLM is not uniquely bad software. It's useful, actively maintained, and the maintainers have responded quickly to each of these disclosures. The pattern is bigger than one library: teams that stand up AI infrastructure quickly — which is almost everyone right now — aren't applying the same security posture to their AI tooling that they'd apply to, say, a web application exposed to the internet. But the AI gateway that holds all your model credentials and sits in front of all your AI workflows deserves to be treated like production infrastructure, because that's exactly what it is.
Updating to v1.83.14-stable takes about 10 minutes. Cleaning up after a compromised AI API key takes considerably longer.
We help small teams build AI infrastructure that's actually maintained and secured — not just stood up and forgotten. If your team has LiteLLM or similar AI gateway tooling running somewhere, we can help you audit it.