Researchers at Obsidian Security have disclosed a critical vulnerability chain (CVSS 9.9) in LiteLLM, an open-source AI gateway, that allows a low-privilege account to achieve full server takeover and execute arbitrary code. This severe flaw, impacting how LiteLLM handles virtual API keys and custom guardrails, exposes sensitive provider keys, encrypted credentials, and all data passing through the proxy.
The compromised LiteLLM server could grant attackers access to every provider key it holds, the secrets used to decrypt stored credentials, and all prompts and responses transmitted through the gateway. BerriAI, the maintainer of LiteLLM, has released a comprehensive fix in version v1.83.14-stable, urging users to upgrade immediately to mitigate these risks.
Understanding the LiteLLM Vulnerability Chain
The exploitation stems from a sequence of three interconnected vulnerabilities, beginning with CVE-2026-47101, an authorization bypass. When a standard user generates a virtual API key, LiteLLM initially stores the user-provided `allowed_routes` field without adequate validation against the user’s role. This oversight allows a non-administrator to create a key with a wildcard, such as `[“/*”]`, effectively granting access to administrative routes that should otherwise be restricted.
This bypass opens the door to subsequent vulnerabilities within the LiteLLM handlers, many of which operate under the assumption that the preceding authorization checks have already been performed. This blind trust creates pathways for privilege escalation.
Privilege Escalation and Code Execution
One such pathway is CVE-2026-47102, a privilege escalation vulnerability. The `/user/update` endpoint, intended for self-service profile modifications, lacks sufficient restrictions on which fields a user can alter. Consequently, a user can update their own record to include `user_role: “proxy_admin”`, thereby elevating their privileges to full administrator status. While an `org_admin` can access this endpoint legitimately, a default `internal_user` can exploit it after bypassing the initial route gate.
Concurrently, CVE-2026-40217 presents a sandbox escape within the Custom Code Guardrail feature. This guardrail compiles and executes Python code provided by administrators. However, in production environments, the `exec()` function was utilized without robust source-level filtering. When `exec()` is invoked with a `globals` dictionary lacking `__builtins__`, Python implicitly injects the full builtins module, providing access to functions like `__import__`, `open`, and `eval`. This grants an attacker the ability to execute arbitrary commands, such as initiating a reverse shell via `os.system`. A separate sandbox escape, identified independently by X41 D-Sec, also allows for server-side code execution via runtime bytecode rewriting on the `/guardrails/test_custom_code` playground endpoint.
Implications of a LiteLLM Server Takeover
A successful exploitation of this LiteLLM vulnerability chain provides an attacker with access to a wealth of sensitive information stored and processed by the gateway. This includes the master key, the salt key required to decrypt stored credentials, and the database URL. Furthermore, all configured provider keys for services such as OpenAI, Anthropic, Gemini, Bedrock, and Azure become accessible. While keys stored in the database are encrypted, they can be recovered using the salt key.
Beyond credential theft, every prompt and response passing through the compromised LiteLLM proxy becomes readable. This can expose personally identifiable information (PII), proprietary source code, internal support tickets, and inadvertently pasted secrets. If the proxy also functions as a Model Context Protocol (MCP) or agent gateway, attackers could gain access to OAuth tokens and tool credentials.
The most formidable risk, however, lies not just in data exfiltration but in the ability to manipulate data in transit. A compromised LiteLLM proxy sits directly between an AI agent and its underlying model. This strategic position allows an attacker to alter responses before they reach the agent, potentially causing the agent to act on forged information. Obsidian demonstrated this by using LiteLLM’s callback mechanism, an extension point often hidden from administrative oversight, to swap a model’s legitimate response with a malicious tool call and rewrite the safety-check context to approve the fabricated action, ultimately leading to a reverse shell on a developer’s machine.
Separately, LiteLLM provides an intentional code execution path for administrators via its MCP support, allowing the registration of stdio MCP servers executed as local subprocesses. While not a bug, reaching administrator privileges effectively grants code execution capabilities. Obsidian reproduced a reverse shell this way on an unpatched version, and a related vulnerability (CVE-2026-42271) in the same MCP machinery was actively exploited and added to CISA’s Known Exploited Vulnerabilities catalog.
This incident follows a series of security challenges for LiteLLM this year, including a supply-chain attack that backdoored two releases in March and a critical SQL injection vulnerability exploited within 36 hours of disclosure in April. While Obsidian frames the current chain as a disclosed flaw rather than active exploitation in the wild, the LiteLLM proxy’s central role continues to make it an attractive target for malicious actors.
Mitigation and Recommendations
To address these critical vulnerabilities, users are strongly advised to upgrade to LiteLLM version v1.83.14-stable or a later release, which contains the complete set of fixes. Following the upgrade, a thorough audit of the LiteLLM deployment is recommended.
It is crucial to re-verify all accounts assigned the `proxy_admin` role, treating this privilege with the same level of security as direct host-level access. Reviewing all Custom Code Guardrails configured on the proxy is also essential to identify any potentially malicious or misconfigured rules. Pay close attention to callbacks loaded from the `config.yaml` file under `litellm_settings.callbacks`, as these are not typically visible in the console and could serve as a hiding place for post-exploitation activities.
Verifying the integrity of the deployed code, beyond just the configuration files, is paramount. If there is any suspicion of exposure, immediate action should be taken to rotate all provider keys, database credentials, and any stored MCP tokens to prevent further unauthorized access. A compromised LiteLLM proxy poses a significant threat by not only leaking data but also by actively manipulating the communication between AI agents and models, underscoring the importance of trust at every layer of the system.
Looking ahead, the focus will be on ensuring widespread adoption of the patched LiteLLM versions and continued vigilance from security teams in auditing their deployments. The ongoing trend of vulnerabilities in AI infrastructure highlights the need for robust security practices and rapid patching cycles within the rapidly evolving AI ecosystem.