A severe security vulnerability chain, consisting of three distinct flaws, has been discovered in LiteLLM, a widely adopted open-source AI gateway. Researchers at Obsidian Security have revealed that these vulnerabilities, when chained together, allow a default low-privilege account to escalate to full administrative privileges and subsequently execute arbitrary code on the server. This critical breach could expose every provider key held by the gateway, decrypt stored credentials, and grant access to all prompts and responses traversing the system, posing a significant risk to organizations leveraging the platform for their artificial intelligence operations.
LiteLLM, maintained by BerriAI, serves as a crucial intermediary in the burgeoning AI ecosystem. It acts as an "AI gateway," brokering calls to over 100 different large language model (LLM) providers through a single, OpenAI-compatible interface. This abstraction layer simplifies AI model integration for developers, allowing them to switch between providers like OpenAI, Anthropic, Google Gemini, Amazon Bedrock, and Azure without re-architecting their applications. Its widespread deployment underscores the gravity of the disclosed vulnerabilities, as a compromise at this central chokepoint grants attackers a panoramic view and control over an organization’s AI interactions. Obsidian Security has rated the full chain with a CVSS score of 9.9, placing it firmly within the "Critical" severity range, necessitating immediate attention from all users.
The maintainer, BerriAI, acted swiftly to address these critical issues, including the complete fix set in LiteLLM v1.83.14-stable, which was released on GitHub on May 2nd. Users are strongly urged to upgrade to this release or a later version without delay to mitigate the risks associated with this three-CVE chain.
The Anatomy of the Attack Chain: Three Critical Vulnerabilities
The intricate attack chain hinges on the successful exploitation of three distinct vulnerabilities, each playing a crucial role in escalating privileges and achieving remote code execution.
1. CVE-2026-47101: Authorization Bypass via Virtual API Key Generation
The initial link in this chain is an authorization bypass identified as CVE-2026-47101. This vulnerability resides in LiteLLM’s handling of virtual API key generation. When a regular user, typically an internal_user with limited privileges, attempts to generate a virtual API key, the system stores the caller-supplied allowed_routes field without adequately validating it against the user’s assigned role.
The allowed_routes field is intended to define and restrict the scope of actions a newly generated key can perform. However, due to this flaw, the LiteLLM proxy inadvertently treats this field as a fallback grant. This allows a non-administrative user to mint a key with allowed_routes: ["/*"], a wildcard entry that effectively grants access to every route within the system, including those explicitly designated for administrators only. The same unchecked write vulnerability was found to exist across other key-management endpoints, necessitating multiple pull requests for a comprehensive fix. By bypassing the intended route restrictions, an attacker gains access to handlers that were presumed to be secure behind an authentication gate, thus setting the stage for further compromise.
2. CVE-2026-47102: Privilege Escalation to Proxy Admin
With the route gate effectively bypassed by CVE-2026-47101, handlers that were previously unreachable become accessible. Several of these handlers operate under the assumption that the route gate has already performed the necessary authorization screening, leading to the second critical vulnerability: CVE-2026-47102, a privilege escalation flaw.
Specifically, the /user/update endpoint, designed to allow users to modify their own records, fails to adequately restrict which fields can be written. An attacker, now able to reach this endpoint due to the prior authorization bypass, can submit a self-update request that includes user_role: "proxy_admin". This malicious request is accepted and saved by the system, effectively promoting the internal_user to a full proxy_admin role. While an org_admin could legitimately access this endpoint, the flaw allows an internal_user to reach it illicitly after exploiting CVE-2026-47101. VulnCheck, which assigned this CVE, has scored it 8.7 under CVSS 4.0 and 8.8 under CVSS 3.1, highlighting its significant impact on system integrity and confidentiality.
3. CVE-2026-40217: Sandbox Escape Leading to Remote Code Execution
The final, and perhaps most devastating, vulnerability in the chain is CVE-2026-40217, a sandbox escape found within LiteLLM’s Custom Code Guardrail feature. This feature allows administrators to compile and run custom Python code. The production endpoints, however, executed this code using exec() without any effective source-level filtering or secure environment configuration.
Crucially, when Python’s exec() function is provided with a globals dictionary that lacks the __builtins__ entry, Python silently injects the full builtins module. This injection grants the executing code access to powerful functions such as __import__, open, and eval. An attacker, having achieved proxy_admin privileges through the previous steps, could then deploy a simple payload, such as one calling os.system, to execute arbitrary shell commands, thus establishing a reverse shell on the compromised server.
Independently, X41 D-Sec discovered a separate path to this sandbox escape on the /guardrails/test_custom_code playground endpoint. Their research demonstrated that a regex deny-list, intended to restrict malicious code, could be defeated through runtime bytecode rewriting, ultimately also leading to server-side code execution. Both paths confirm the profound insecurity of the Custom Code Guardrail implementation prior to the patch.
The Profound Implications of a Compromised AI Gateway
The strategic position of LiteLLM as an AI gateway means that a full compromise has far-reaching consequences, extending beyond typical data breaches.
Data Exposure: A successful exploitation of this chain exposes a wealth of sensitive information. This includes the master key and the salt key, which are critical for decrypting stored credentials. Additionally, every configured provider key for all integrated LLMs (OpenAI, Anthropic, Gemini, Bedrock, Azure, etc.) becomes accessible. While keys in configuration files or environment variables might be stored in plaintext, those in the database are encrypted but become fully recoverable with the stolen salt key.
Furthermore, every piece of data transmitted through the gateway—both prompts and responses—becomes readable by the attacker. In real-world deployments, this data often includes highly sensitive information such as Personally Identifiable Information (PII), proprietary source code, internal company tickets, and embedded secrets, all of which could be exfiltrated.
Active Manipulation and Supply Chain Attacks: Beyond passive data theft, the more insidious threat lies in an attacker’s ability to actively manipulate AI interactions. Because the gateway sits directly on the communication wire between an AI agent and the LLM, a compromise allows the attacker to alter responses in transit.
Obsidian Security vividly demonstrated this capability against Claude Code routed through a compromised LiteLLM proxy. This is distinct from prompt injection, where an attacker tries to trick the model itself into misbehaving. Instead, the attacker leverages LiteLLM’s built-in callback mechanism—an extension point that fires on every request and is typically hidden from the administrative UI. By injecting malicious code into these callbacks, the attacker can swap the model’s legitimate response for a forged tool call and even rewrite the safety-check context to make the malicious action appear approved. In their demonstration, a developer typing a single word, "hello," resulted in the attacker popping a reverse shell on the developer’s machine, showcasing a devastatingly effective supply chain attack against AI-driven development workflows.
If the LiteLLM proxy is also configured to run as a Model Context Protocol (MCP) or agent gateway, then OAuth tokens and other tool credentials managed by these systems also fall within the attacker’s scope, amplifying the potential for lateral movement and further system compromise.
Intentional Code Execution Paths and Related Incidents
It’s important to note that LiteLLM, by design, offers certain intentional code execution paths for proxy_admin users. Its MCP support allows an administrator to register stdio MCP servers, which the proxy then launches as local subprocesses. While this is a design trade-off for functionality rather than a bug, reaching proxy_admin privileges, as enabled by this vulnerability chain, effectively grants an attacker host-level code execution. Obsidian reproduced a reverse shell through this method on LiteLLM v1.88.0.
This incident also highlights a broader pattern of security challenges for LiteLLM this year:
- CVE-2026-42271 (May 2026): A genuine bug in the same stdio-MCP machinery allowed callers to spawn subprocesses through LiteLLM’s MCP preview endpoints. This vulnerability was reportedly exploited in the wild and was added to CISA’s KEV (Known Exploited Vulnerabilities) catalog earlier this month, underscoring its critical nature and active threat.
- Supply Chain Compromise (March 2026): In a significant incident, a supply-chain attack backdoored two LiteLLM releases on PyPI, distributing malicious versions of the software. This event highlighted the fragility of software dependencies and the potential for compromise at the very source of widely used packages.
- Critical SQL Injection (April 2026): A critical SQL injection vulnerability (CVE-2026-42208) was exploited within a mere 36 hours of its disclosure, demonstrating the speed with which attackers can weaponize newly revealed flaws in popular platforms.
These prior incidents underscore that LiteLLM, due to its central role in the AI infrastructure, remains a high-value target for threat actors. While Obsidian’s latest disclosure frames this specific chain as a demonstrated flaw rather than observed in-the-wild exploitation, the history suggests that such critical vulnerabilities are quickly leveraged by malicious actors.
Urgent Action and Long-Term Security Posture
Given the critical nature and ease of exploitation of this vulnerability chain, immediate action is paramount for all organizations utilizing LiteLLM.
Immediate Mitigation Steps:
- Upgrade Immediately: The most crucial step is to upgrade all LiteLLM deployments to v1.83.14-stable or any later version. This release contains the complete set of fixes for the three CVEs discussed.
- Conduct a Thorough Audit: After upgrading, organizations must conduct a comprehensive security audit.
- User Roles: Re-verify every account that holds
proxy_adminprivileges. Treat this role as equivalent to host-level access, understanding the extensive control it grants. - Custom Code Guardrails: Review every Custom Code Guardrail configured on the proxy. Ensure no malicious or unverified code has been introduced.
- Hidden Callbacks: Critically, check the callbacks loaded from
config.yamlunderlitellm_settings.callbacks. These do not appear in the console and are prime locations for a post-RCE attacker to hide persistent malicious code. - Code Integrity: Verify the integrity of the deployed code itself, not just the configuration files, to ensure no backdoors were injected during a potential compromise.
- User Roles: Re-verify every account that holds
- Credential Rotation: If there is any suspicion of exposure or if the system was running a vulnerable version, immediately rotate all sensitive credentials:
- Rotate all provider keys (OpenAI, Anthropic, Gemini, etc.).
- Change database credentials.
- Rotate any stored MCP tokens.
Broader Implications for AI Security and Best Practices:
This incident serves as a stark reminder of the evolving threat landscape in the age of AI. The unique characteristic of an AI gateway compromise is its ability to not only leak data but also to actively forge and manipulate the responses that AI agents act upon, fundamentally undermining the trust in AI systems. The chain of vulnerabilities reveals a pattern of misplaced trust at multiple layers: the route gate trusted caller-supplied fields without verification, the handlers trusted the route gate implicitly, and ultimately, critical security checks were absent at key junctures.
Organizations leveraging AI technologies must adopt a proactive and layered security approach:
- Zero Trust Principles: Implement zero-trust principles, where no user, application, or system is inherently trusted, regardless of its location within the network.
- Continuous Security Audits: Regularly audit open-source components and AI infrastructure for vulnerabilities.
- Input Validation and Sanitization: Rigorously validate and sanitize all inputs, especially when dealing with code execution or privilege-sensitive operations.
- Least Privilege: Enforce the principle of least privilege for all users and services, granting only the necessary permissions to perform their functions.
- Runtime Monitoring: Implement robust runtime monitoring and logging for AI gateways and applications to detect anomalous behavior that could indicate a compromise.
- Secure Development Practices: Encourage and enforce secure development lifecycle practices within development teams, especially for critical infrastructure components.
The rapid advancements in AI are accompanied by new security paradigms. Incidents like the LiteLLM vulnerability chain highlight the urgent need for developers and organizations to prioritize security at every stage of AI integration and deployment, ensuring the integrity and trustworthiness of these transformative technologies.
