LiteLLM Vulnerability Chain Lets Low-Privilege Users Take Over AI Gateway Servers

# Critical Vulnerability Chain in LiteLLM AI Gateway Allows Complete Server Takeover from Default User Account

## The Threat

LiteLLM is a widely deployed open-source AI gateway that sits at a critical infrastructure chokepoint: it brokers API calls to over 100 model providers—OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure—behind a unified OpenAI-compatible interface. Thousands of organizations use it to centralize AI access, token management, and audit logging. On June 15, Obsidian Security disclosed a three-vulnerability chain that allows a low-privilege internal user account to escalate to full administrative control and achieve unauthenticated remote code execution on the server.

The chain exploits a fundamental design flaw: LiteLLM's authorization layer assumes that handlers behind authenticated checkpoints will enforce their own permission boundaries. They don't. An attacker with a basic user account can bypass route restrictions, promote themselves to proxy admin, and exploit a sandbox escape in the Custom Code Guardrail feature to run arbitrary Python on the host. The researchers rated the complete chain CVSS 9.9—Critical severity.

The blast radius is severe. A compromised LiteLLM instance exposes the master encryption key, the salt key that decrypts stored credentials, and every configured provider API key in plaintext or recoverable form. This includes keys for OpenAI, Anthropic, Gemini, Bedrock, and other services. Every prompt and response flowing through the gateway—often containing source code, internal documentation, configuration details, and secrets pasted by developers—becomes readable. For organizations running LiteLLM as an agent gateway or Model Context Protocol (MCP) server, OAuth tokens and tool credentials are also at risk. Worse still, an attacker can inject callbacks that silently rewrite model responses in transit, a form of supply-chain poisoning that is neither prompt injection nor detectable in audit logs.

BerriAI, the maintainer, patched all three CVEs in LiteLLM v1.83.14-stable, released May 2, 2026. Any deployment still running older versions is exploitable.

## Severity and Impact

| CVE | CVSS v4.0 | CVSS v3.1 | CWE | Attack Vector | Attack Complexity | Privileges Required | User Interaction |

|---------|---------------|---------------|---------|-------------------|-----------------------|------------------------|----------------------|

| CVE-2026-47101 | 6.5 | 6.5 | CWE-639 (Authorization Bypass) | Network | Low | Low | None |

| CVE-2026-47102 | 8.7 | 8.8 | CWE-639 (Improper Authorization) | Network | Low | Low | None |

| CVE-2026-40217 | 9.8 | 9.9 | CWE-693 (Protection Mechanism Failure) | Network | Low | Low | None |

| Full Chain | 9.9 | 9.9 | Multiple | Network | Low | Low | None |

## Affected Products

- All open-source deployments running versions before May 2, 2026

- Self-hosted instances without automated security updates

- Private deployments in cloud and on-premise environments

Unaffected:

## Mitigations

Immediate Actions:

1. Upgrade LiteLLM to v1.83.14-stable or later. This release includes complete fixes for all three CVEs in the chain. Check your deployment: pip show litellm | grep Version or consult your container image tag.

2. Rotate all provider keys that were accessible through the compromised instance, including OpenAI, Anthropic, Gemini, Bedrock, and Azure credentials. Do not assume the keys were accessed—rotate them immediately.

3. Rotate the encryption salt key and master key used by LiteLLM. These keys decrypt all stored credentials in the database. Regenerate them and re-encrypt the credential store.

4. Review audit logs for any user promotion events (user_role updates to proxy_admin), route privilege escalations, or guardrail test endpoint access from non-admin accounts. These are indicators of exploitation.

Preventative Measures:

## References

## HackWire Analysis

This vulnerability chain exposes a critical architectural assumption that undermines modern API gateway design. LiteLLM's developers trusted that permission checks at the route layer would be redundant with per-handler validation—a layered defense strategy that only works if all layers actually validate. By skipping field-level authorization in the user update endpoint, they created a situation where a caller could directly edit their own role. This is not a subtle bug; it's a fundamental misunderstanding of the trust boundary.

The timing compounds the risk. LiteLLM exploded in adoption in 2025-2026 as enterprises rushed to centralize AI access through a single gateway, locking in provider keys and audit logging. Many of these deployments are running unpatched versions because update cycles for infrastructure tools are slow and organizations assume open-source AI projects receive rapid security patches—a reasonable assumption that broke here. A May 2 patch sitting unreleased until June 15 is a three-week window where every LiteLLM instance on the internet was exploitable.

The sandbox escape deserves special attention. The Custom Code Guardrail feature uses exec() in Python with a crippled globals dict, expecting Python to refuse to inject builtins. This is security by wishful thinking. Python explicitly restores __builtins__ when missing, and this behavior is documented in the language specification. A separate finding by X41 D-Sec exploited bytecode rewriting to defeat a regex deny-list, showing that even defenders trying to be clever were outmaneuvered. Both paths led to OS-level code execution with the privilege level of the LiteLLM process.

The most insidious risk is the callback injection attack. LiteLLM allows admin users to define callbacks that run on every request—ostensibly for logging or custom behavior. An attacker with admin access can inject a callback that rewrites model responses in transit, poisoning outputs before they reach the user. This is not prompt injection; the model never sees the modification. From the user's perspective, the compromised proxy is invisible, and the model response appears to come directly from the AI service. For agents making tool calls or executing code based on model outputs, this could lead to silent execution of attacker-supplied code. Organizations relying on LiteLLM to broker Claude, GPT-4, or other frontier models should assume their deployment is compromised if they have not yet upgraded.

— HackWire Editorial

## Related Coverage