LiteLLM CVE-2026-47101, -47102, -40217: From a Low-Privilege User to proxy_admin and RCE — a Three-Bug Chain in the AI Gateway

TL;DR — 90 seconds

Affected?

All LiteLLM proxy deployments prior to version v1.83.14-stable with multiple user roles (in particular internal_user accounts) and/or active Custom Code Guardrails.

Risk?

Three individually serious flaws (CVSS 4.0 ~8.7 each) can be chained: CVE-2026-47101 lets an internal_user unlock access to admin routes via allowed_routes; CVE-2026-47102 allows self-escalation to proxy_admin via /user/update; CVE-2026-40217 allows arbitrary Python code execution through a sandbox flaw in the Custom Code Guardrail. Combined: from an ordinary internal account to full RCE on the proxy server.

Immediate action?

Upgrade to litellm >= 1.83.14-stable. Audit all proxy_admin assignments, review Custom Code Guardrails in config.yaml for unauthorised changes (not always visible in the UI).

Recommendation?

Anyone running LiteLLM as a central AI gateway with multiple user roles should patch promptly and rotate provider API keys and DB credentials as a precaution. No confirmed in-the-wild exploitation is known, but a publicly documented proof-of-concept exists.

Criticality?

high — not an unauthenticated pre-auth RCE, but the chain starts at any ordinary internal account and ends in full server compromise.

What is the problem?

LiteLLM is an open-source AI gateway/proxy that bundles unified access to over 100 different LLM providers (OpenAI, Anthropic, Azure, Bedrock and more) and is typically run centrally within an organisation — with access to every provider API key and, often, to internal databases for budget tracking, user management and logging. Three independently discovered but combinable flaws let a user with the lowest default role (internal_user) work their way up to full administrator and, ultimately, execute arbitrary code on the proxy server:

CVE-2026-47101 — authorization bypass on key generation

Endpoints such as /key/generate accept an allowed_routes field that determines which API routes a newly created key may access. LiteLLM does not validate whether the requested routes match the requesting user's role (CWE-863, Incorrect Authorization) — an internal_user can mint a key for themselves that reaches routes normally reserved for admins.

CVE-2026-47102 — self-escalation to proxy_admin

The /user/update and /user/bulk_update endpoints do not check, at the field level, which attributes a user may change on their own account. With the access gained via CVE-2026-47101, a user can set their own user_role field directly to proxy_admin, gaining full administrative rights on the instance.

CVE-2026-40217 — sandbox escape in the Custom Code Guardrail

LiteLLM lets administrators configure so-called “Custom Code Guardrails” — user-defined Python code that inspects or transforms prompts/responses before processing. This code is executed via exec() without stripping __builtins__ from the execution context: __import__, open and eval remain reachable, effectively allowing arbitrary code execution. A regex-based deny-list filter on the playground endpoint can additionally be bypassed through bytecode manipulation. With the proxy_admin rights gained via CVE-2026-47101/-47102, an attacker can configure and trigger a malicious guardrail.

Who is affected?

All three CVEs affect the LiteLLM proxy server itself (not the client-side SDK library). Since the exact lower version boundary is not stated consistently across available sources, the practical rule is: treat any production instance below v1.83.14-stable as affected.

Impact

In typical deployments, the proxy server is a highly privileged central node: it holds provider API keys for every connected LLM service, database credentials for its own user/budget management, encrypted stored secrets (recoverable if the salt key is known), and every prompt and response that passes through it — potentially including personal data and internal source code sent to an LLM for analysis.

An attacker who completes the full chain gains code execution with the privileges of the proxy process. That means full access to all the secrets named above, the ability to read or redirect traffic to every connected LLM provider, and, depending on network segmentation, a pivot point into internal systems. The chain requires an authenticated account below proxy_admin as its starting point — a pre-auth attack with no credentials at all is not the path here, but any internal or accidentally over-provisioned account is.

Mitigation / immediate steps

Operational decision block

• Act now if … your LiteLLM instance actively uses multiple user roles (not just a single proxy_admin account) and/or has Custom Code Guardrails configured.
• Check with priority if … LiteLLM runs as a central, company-wide AI gateway with access to multiple provider API keys.
• Next regular window if … this is a single-user test instance with no production secrets.

Step 1 — upgrade to v1.83.14-stable or newer

# check the current version
pip show litellm | grep Version
# or in a Docker deployment:
docker exec <litellm-container> pip show litellm

# upgrade (pip installation)
pip install "litellm>=1.83.14"

# upgrade (Docker)
docker pull ghcr.io/berriai/litellm:main-v1.83.14-stable
# adjust docker-compose.yml / Helm chart to the new tag and redeploy

Step 2 — audit proxy_admin assignments

# list all users with their current role (proxy admin API, example)
curl -s -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  <litellm-host>/user/list | jq '.users[] | {user_id, user_role}'

# filter specifically for unexpected proxy_admin assignments
curl -s -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  <litellm-host>/user/list | jq '.users[] | select(.user_role=="proxy_admin")'

Any proxy_admin assignment that cannot be clearly attributed to a known, authorised administrator should be reset immediately.

Step 3 — review Custom Code Guardrails and disable if needed

# search config.yaml for guardrail definitions — not always fully visible in the UI
grep -A 10 "guardrails:" config.yaml

# until patched: disable custom-code guardrails or restrict them to known,
# reviewed code instead of allowing user input in the configuration

Step 4 — if compromise is suspected: rotate secrets

Rotate provider API keys (OpenAI, Anthropic, Azure, Bedrock etc.), the LiteLLM instance's database credentials, and the master/salt key as soon as unauthorised proxy_admin access is suspected.

Detection / verification

Check the version

pip show litellm | grep Version
# or in a running container:
docker exec <litellm-container> python -c "import litellm; print(litellm.__version__)"

Check for suspicious role changes

# search audit/access logs for calls to /user/update and /user/bulk_update
# where user_role was changed to proxy_admin
grep -E "/user/(bulk_)?update" litellm.log | grep -i "proxy_admin"

# find key-generation calls with a suspicious allowed_routes field
grep "/key/generate" litellm.log | grep -i "allowed_routes"

Check guardrail configuration for unknown code

# list all custom-code guardrails referenced in config.yaml and diff against
# the last known, reviewed version
git diff HEAD~10 -- config.yaml | grep -A 20 "guardrails:"

Since no publicly confirmed in-the-wild exploitation is documented, there are no established third-party IOCs — the checks above serve to verify whether the flaws have already been exploited on your own instance, not to match against known attack patterns.

Operator guidance

Mid-market

Upgrade to v1.83.14-stable or newer promptly, especially if LiteLLM is available to multiple teams with different roles. An emergency weekend rollout is not strictly necessary absent confirmed exploitation, but a patch window within a few days is warranted given the combination of severity and the proxy server's central role.

Enterprise / multi-tenant

Full audit of all proxy_admin assignments and active Custom Code Guardrails before updating, since the flaws could have been exploited prior to patching. After updating: rotate all provider API keys and database credentials as a precaution if internal user roles are assigned more broadly than operationally necessary.

If you run LiteLLM with a single admin account only

The direct escalation risk is lower, since no separate internal_user account exists as an entry point. An upgrade is still recommended, since future team growth or integrations (such as CI/CD systems with their own API keys) can create new internal accounts below proxy_admin.

Decision block

Act today if: multiple user roles are active and/or Custom Code Guardrails are configured. Within a few days if: LiteLLM runs in production but with only one admin account. Regular maintenance window if: this is an isolated test instance with no production secrets.

Conclusion

This three-bug chain is a textbook example of why authorization checks must be enforced not just per endpoint but consistently at the field and role level: each of the three flaws is already serious on its own, but their combination — from an ordinary internal account to full server compromise — shows how quickly seemingly isolated bugs can become a complete compromise chain. For a central AI gateway like LiteLLM, which typically bundles access to an organisation's entire set of provider secrets, the consequence is clear: strict least-privilege for internal roles, caution with user-defined code in guardrails, and a patch cadence that doesn't wait for active exploitation.

Sources

• GitHub Advisory Database — GHSA-qrc4-49gv-mv9m (CVE-2026-47101)
• Obsidian Security — Breaking LiteLLM: From Low-Privilege User to Admin and RCE
• The Hacker News — LiteLLM Vulnerability Chain Lets Low-Privilege Users Take Over AI Gateway Servers
• GitHub — BerriAI/litellm Security Advisories