Brief · Builders
LiteLLM's admin-escalation bug: old news, and the fix is already out
Quick update, not a full brief. Other sites are writing up LiteLLM CVE-2026-114612 this week. It isn't new: the CVE went public Oct 22, the GitHub advisory followed Oct 27, and the fixed releases shipped Sep 30. If you've updated LiteLLM since October, you're probably fine already.
Here's the short version. Someone with a logged-in internal_user account on your LiteLLM proxy can forge an admin credential, become proxy_admin, and then run commands on the host through the MCP stdio endpoint. The CNA scores it 9.9 Critical. It does need an existing account, though, so attackers can't just walk in off the internet.
I found no exploitation. CISA's KEV catalog doesn't list it, CISA's SSVC rating says "Exploitation: none", and the GitHub advisory reports none.
Fixed versions
- 1.100.4 (for anything up to 1.100.x)
- 1.101.3
- 1.102.2
- 1.103.1
- 1.104.0-rc.2 (release candidate)
One wrinkle: versions 1.87.0 through 1.90.x are only exploitable if EXPERIMENTAL_UI_LOGIN is turned on. From 1.91.0 onward, the default setup is exploitable.
What to do
-
Upgrade to the fixed version for your line, or anything current.
- Why: the CVE record lists fixes in 1.100.4, 1.101.3, 1.102.2, 1.103.1, and 1.104.0-rc.2.
- How: check your proxy image tag or run
pip show litellm. Skip 1.107.0, which was the trojanized release from our earlier coverage.
-
Can't upgrade today? Set
EXPERIMENTAL_UI_LOGIN=false.- Why: the advisory says this "disables the vulnerable authentication path but also breaks CLI SSO and Claude Code gateway login."
- How: set the environment variable, restart the proxy, and warn your users that CLI SSO and Claude Code gateway login will stop working.
Two more from Nov 4
DeepSeek Harness (CVE-2026-82033). Its web profile's RPC had no authentication, so any local process, even one running as a different OS user, could run the agent's bash and file tools with your model credentials and skip the approval checks. Fixed in dsh-v0.1.2-alpha.2. No exploitation reported.
Jan (CVE-2026-122235). Jan's workspace guard checked where a symlink sat, not where it pointed. Per Jan's advisory, a dangling link "was never actually resolved," and the approval prompt "only displayed the workspace path." So a malicious repo could use prompt injection to make the write and edit tools create files outside the workspace, such as ~/.ssh/authorized_keys. Affects 0.8.5 up to 0.8.8. Fixed in 0.8.8. No exploitation reported.
Different bugs, one lesson: each check trusted the wrong thing. LiteLLM trusted any token that decrypted with its key, even though the same key also sealed stored secrets. DeepSeek Harness's control plane had no authentication at all. Jan's guard was fooled by a symlink that pointed nowhere yet.
For the bigger picture on AI servers left open, see our ai-servers brief.
Want the next one?
One email, weekly-ish. The week's briefs, how worried to be, and what to do about it. No doom.
Subscribe on Beehiiv ↗Free. Opens Beehiiv in a new tab. Unsubscribe whenever, I won't be offended.