On May 2, 2025, BerriAI released LiteLLM v1.83.14-stable, fixing a vulnerability chain that allowed low-privilege users to execute arbitrary code on the AI gateway server. Obsidian Security disclosed the chain—tracked as CVE-2026-47101, CVE-2026-47102, and CVE-2026-40217—with a combined CVSS score of 9.9 (Critical).
If your team uses LiteLLM to manage access to OpenAI, Anthropic, or other model providers, this analysis reveals which controls failed and what you need to audit immediately.
What Happened
The attack began with a default low-privilege account in LiteLLM's access control system. An attacker with this access could exploit three vulnerabilities in sequence:
- Escalate privileges from low-privilege user to full administrator.
- Inject malicious input through insufficient validation.
- Execute arbitrary code on the server.
The gateway's role as a central proxy for AI model requests made this particularly dangerous. A compromised gateway can alter model responses, inject malicious prompts, or exfiltrate every query and response in your AI infrastructure.
Timeline
Initial access: Attacker authenticates using a low-privilege default account (CVE-2026-47101).
Privilege escalation: Exploits access control flaw to gain admin rights (CVE-2026-47102).
Code execution: Uses admin privileges to inject and execute code through unvalidated input (CVE-2026-40217).
Disclosure: Obsidian Security reports the chain to BerriAI.
Patch release: BerriAI ships complete fix in v1.83.14-stable on May 2.
The speed of the chain is critical. An attacker can reach code execution within minutes, not days.
Which Controls Failed
Default credentials remained active in production. The low-privilege account should not have existed in a deployed system. This failure is akin to the "admin/admin" breaches but with a low-privilege account as the entry point.
Role-based access control (RBAC) didn't enforce least privilege. The system allowed actions that should have required admin rights. User role boundaries weren't enforced at the API level.
Input validation was missing or incomplete. Once admin privileges were gained, malicious input could be injected and executed as code. The gateway trusted admin-supplied data without sanitization.
No defense in depth. A single privilege escalation gave the attacker full access. There was no secondary authorization layer for destructive actions, no monitoring for unusual privilege changes, and no rate limiting on sensitive API calls.
What the Standards Require
OWASP ASVS v4.0.3 Requirement 4.1.1: "Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed."
The LiteLLM chain bypassed access controls due to inconsistent enforcement. Your gateway must validate authorization at every API endpoint.
OWASP ASVS Requirement 5.3.1: "Verify that output encoding is relevant for the interpreter and context required."
The code execution vulnerability violates this directly. Even admin-supplied input must be treated as untrusted data in execution contexts.
NIST 800-53 Rev 5 Control AC-6 (Least Privilege): "Employ the principle of least privilege, allowing only authorized accesses necessary to accomplish tasks."
Default accounts with any privilege level violate least privilege. Remove or disable default credentials before handling production traffic.
PCI DSS v4.0.1 Requirement 8.2.2: "Default passwords/passphrases on system components are changed before or immediately after installation."
If processing payment data through AI-enhanced systems, this requirement applies to your AI gateway. Remove default accounts.
Lessons and Action Items
Audit your AI gateway configuration today. Check for:
- Default accounts (any privilege level)
- Shared credentials across environments
- Service accounts with excessive permissions
- Admin actions that don't require re-authentication
Test your RBAC boundaries. Create a test account with the lowest privilege level. Attempt to:
- Access admin-only API endpoints
- Modify configuration through API calls
- Read secrets or credentials
- Change other users' permissions
If any succeed, you have a vulnerability.
Treat admin input as untrusted. Review every place your gateway accepts configuration, model parameters, or custom prompts. Ask:
- Does this input flow into eval(), exec(), or system calls?
- Could an attacker inject shell commands through this field?
- Are we validating format and content?
Implement monitoring for privilege changes. Alert when:
- A user's role changes
- A new admin account is created
- API keys are generated with elevated permissions
- Configuration files are modified
Patch now if you're running LiteLLM. Version v1.83.14-stable contains the complete fix set. If you can't patch immediately:
- Disable or remove all default accounts
- Restrict admin access to a bastion host or VPN
- Enable detailed audit logging for all API calls
- Monitor for unusual privilege escalation patterns
The LiteLLM chain demonstrates the impact of failing to manage default credentials, enforce RBAC, and validate input. Your AI gateway is critical to your infrastructure. Protect it with the same rigor as your authentication server or secrets vault.
CVE Details
