Overview
Security researchers at Obsidian Security have disclosed a chained vulnerability attack path in LiteLLM, a widely deployed open-source AI gateway used by thousands of organizations to broker calls to over 100 model providers behind a single unified API. The vulnerability chain allows a default low-privilege user account to escalate to full administrator access and ultimately achieve remote code execution (RCE) on the server hosting the gateway.
LiteLLM is used extensively in enterprise AI deployments as a cost-control and model-routing layer, making the reach of this disclosure significant for any organization running self-hosted AI infrastructure.
The Vulnerability Chain
Obsidian Security identified three distinct vulnerabilities that, when chained together, create a critical attack path requiring only a valid low-privilege account — the kind that might be handed to a developer or contractor:
Step 1 — Privilege Escalation to Admin
The first vulnerability involves an access control flaw in LiteLLM's administrative API. A user with the default "internal user" role can invoke endpoints intended only for administrators by manipulating specific request parameters. This allows the attacker to promote their own account to administrator without any approval workflow.
Step 2 — Sensitive Data Access
With elevated admin privileges, the attacker can access stored API keys, model provider credentials, and configuration secrets held by the LiteLLM proxy. For organizations where LiteLLM brokers calls to OpenAI, Anthropic, Azure, or other providers, this means all underlying API keys are exposed.
Step 3 — Remote Code Execution
The final link in the chain involves LiteLLM's support for custom model configurations and callback integrations. An authenticated admin (now attained in Step 1) can inject malicious configuration that triggers code execution on the server when the proxy processes a subsequent model request. The result is unauthenticated-equivalent RCE achievable by anyone with any LiteLLM account.
Affected Deployments
LiteLLM is commonly deployed as:
- A self-hosted proxy within enterprise AI infrastructure
- A component inside AI agent frameworks and agentic pipelines
- A gateway layer in MLOps platforms and internal developer portals
Organizations running LiteLLM proxy versions prior to the patched release should treat this as a critical remediation priority, especially if multiple teams share the same LiteLLM instance with varying trust levels.
Impact
| Consequence | Details |
|---|---|
| Privilege Escalation | Any low-privilege account can become admin |
| Credential Theft | All stored API keys and provider secrets exposed |
| Remote Code Execution | Attacker-controlled code runs on gateway server |
| Supply Chain Risk | Compromised gateway can manipulate all model responses |
The supply chain dimension is particularly concerning: a compromised LiteLLM proxy sits in the critical path of every AI call made by the organization. An attacker with server access could silently modify model responses, exfiltrate prompt data, or use the gateway as a persistent foothold within AI infrastructure.
Recommendations
- Update LiteLLM immediately to the latest patched version
- Audit active user accounts on your LiteLLM instance — remove or revoke any accounts that are no longer needed
- Rotate all API keys stored within LiteLLM, including keys for OpenAI, Anthropic, Azure, AWS Bedrock, and any other providers
- Review access logs for unusual API calls to admin endpoints from non-admin accounts
- Restrict network access to LiteLLM admin endpoints to trusted internal networks only
- Enable authentication on all LiteLLM deployments — unauthenticated or weakly authenticated instances represent the highest risk
Broader Context
This disclosure continues a pattern of AI infrastructure components carrying significant security debt. As organizations race to deploy AI gateways, proxies, and orchestration layers, the security posture of these components often lags behind their adoption speed. Tools like LiteLLM, LangChain, and similar frameworks are increasingly part of critical internal infrastructure — yet they are often deployed with default configurations, minimal access controls, and assumptions of internal trust that do not hold in practice.
The Obsidian Security researchers noted that the attack requires only credentials that might be issued as part of routine developer onboarding, making insider threat or compromised-credential scenarios a realistic attack vector.