CVE-2026-114612: LiteLLM, Admin Takeover, and the Risk of Centralizing Your AI Keys

According to the project's advisory, the proxy uses one encryption key for two purposes: sealing secrets at rest and minting session tokens. An internal user can get crafted metadata containing a forged admin identity encrypted and returned through the API key flow. When that output is replayed as a bearer token, the proxy decrypts it successfully and trusts it.

This is a textbook reason to keep cryptographic purposes separate. Data encrypted by a system is not automatically something that system should trust as a credential. The exposure depends on who holds internal_user access. It may be a handful of colleagues, or it may be every customer, if your product issues accounts on the proxy.

This one needs a different response, because no vulnerable code path is involved. According to LiteLLM's incident report, a malicious litellm==1.107.0 was live on PyPI on October 21 from 11:39:51 to 13:23 UTC. Docker tags v1.107.0, latest, main-latest, and main-stable pointed at a compromised image from 11:46 to 14:20 UTC. The enterprise private registry was not affected.

If anything you run pulled those during that window, upgrading alone is not enough. The project's advice is to rotate everything: every provider key stored in the proxy database, the master and virtual keys, and the database password. Note how easily this could happen without anyone deciding to upgrade. An unpinned install or a container that pulls latest on restart would have been enough.

GHSA-w4c7-34wj-hqm8, published October 27 with no CVE ID, describes an unauthenticated file read on Enterprise proxies. The advisory says reading the process environment exposes LITELLM_MASTER_KEY and provider API keys. Affected versions are those below 1.103.10, 1.104.8, 1.105.6, and 1.106.5 on their respective lines. Open-source deployments without a license are not affected.

Pick a target that clears all three issues. That means a version past the fixes above and not 1.107.0. The project's latest release on November 4 was v1.108.0. Pin it exactly and stop deploying from floating tags.

Then decide about secrets. The advisory for CVE-2026-114612 gives no rotation guidance, and we found none in the release notes. Our view is that if any untrusted or semi-trusted account could reach a vulnerable version, you should treat the keys on that proxy as exposed, since admin access and command execution put them within reach. Check LiteLLM's documentation before changing LITELLM_SALT_KEY, because stored credentials are encrypted with it and a careless change can leave them unreadable.

None of this means you should stop using a gateway. Routing model calls through one place gives you logging, budgets, and failover, and it can keep provider keys out of application code. It does concentrate risk, though, and the proxy deserves the same care as your production database. It often holds the keys to every model account you have, and frequently sees all of your prompts and responses as well.

Reduce the blast radius where you can. Use separate provider keys per environment, and keep spending limits low. Give the proxy process few privileges, disable MCP or admin features you do not use, and watch provider billing dashboards for unusual activity. A hosted gateway is also a reasonable option if you do not want to run this yourself.

A typical AI-built product added LiteLLM in an afternoon, often from a Compose file that tracks a latest tag. That choice makes sense at the prototype stage. When the product has paying customers, a floating tag means someone else's bad day can quietly become your stolen API keys and an enormous model bill.

The work here is not exotic: pinned versions, verified images, scoped keys, rehearsed rotation, and someone who reads advisories for the tools you depend on. Founders rarely have time for it, and AI assistants do not bring it up. If you would like an experienced engineer to review your AI stack and own this work, that is what our production hardening engagements and retainers are for.