LiteLLM Root Access: Chaining IDOR and RCE in AI Gateways
Has anyone else dug into the Obsidian Security disclosure regarding the LiteLLM vulnerability chain? It's a textbook example of why default credentials in AI infrastructure are a nightmare.
The core issue is that a default low-privilege account can leverage an IDOR (Insecure Direct Object Reference) to escalate privileges to admin. Once they're admin, the next step is leveraging the dynamic configuration loading to achieve RCE. Since LiteLLM acts as a central broker for over 100 LLM providers, compromising this gateway exposes every API key (OpenAI, Anthropic, etc.) stored in its database.
The Attack Chain Summary:
- Auth Bypass: Access the default
sk-litemaster key or low-priv user. - Privilege Escalation: Modify user role via API endpoint tampering.
- RCE: Inject malicious model configurations to execute code on the host.
If you are running LiteLLM, you should immediately rotate all master keys and provider API keys. You can audit your logs for suspicious privilege escalation attempts using a query like this:
LiteLLM_AuditLogs
| where Action == "user_update"
| where TargetUser == "admin"
| where InitiatingUser != "admin"
Also, check if the default UI is exposed to the public internet.
What's your take on using these AI gateways in production? Are people actually isolating them in separate VPCs, or are they just dropping them into their Kubernetes clusters and hoping for the best?
We started deploying LiteLLM internally last month for our dev team. This write-up gave me a heart attack. We isolated it immediately behind an internal ALB and disabled the user_update endpoint via nginx config blocks until the patch is verified. It's wild that an AI gateway—something specifically designed to handle secrets—had such a basic flaw in user management logic.
Good catch on the nginx block. I'd also recommend checking your environment variables. If you aren't using a secrets manager for LITELLM_MASTER_KEY and DATABASE_URL, you're doing it wrong. Here is a quick Python snippet to verify if your instance allows unauthenticated role swaps (use with caution):
import requests
target_url = "http://your-litellm-host/api/user/update"
headers = {"Authorization": "Bearer "}
payload = {"user_id": "admin", "role": "admin"}
r = requests.post(target_url, =payload, headers=headers)
print(f"Status: {r.status_code}, Response: {r.text}
From a pentester's perspective, this is similar to the Jenkins script console issues we saw years ago. Anytime you have a web interface that can control the underlying process or configuration, it's game over. The fact that it holds the 'crown jewels' (LLM keys) makes it a prime target. If anyone needs indicators of compromise (IoCs), look for python child processes spawning from the LiteLLM parent process.
Great insights everyone. While patching is priority #1, adding a runtime safety net is vital. Since the RCE leverages dynamic config loading, enforcing a read-only root filesystem in your container definition prevents the attacker from writing payloads to disk. It doesn't stop the initial execution but significantly limits persistence and lateral movement.
securityContext:
readOnlyRootFilesystem: true
Solid advice on hardening, but don't forget detection. Even with a read-only FS, spotting the IDOR attempt or the subsequent RCE is vital. I've deployed Falco rules to monitor for unexpected child processes or shell access spawned by the LiteLLM container. Here’s a basic rule to catch the RCE execution phase:
- rule: LiteLLM Shell Spawns
desc: Detect shell spawned by litellm
condition: spawned_process and proc.name in (bash, sh) and proc.pname contains litellm
output: "Shell spawned by LiteLLM (user=%user.name command=%proc.cmdline)"
priority: CRITICAL
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access