How the attack works
An attacker who already has a low-privilege LiteLLM account (e.g. internal_user) sends a request to the /user/update or /user/bulk_update endpoint. Because these endpoints don't check whether the caller is allowed to change the user_role field, the attacker simply sets it to proxy_admin or admin in the request payload. The bulk_update endpoint also accepts arrays of user objects, so the same trick can escalate one or many accounts in a single call. Once the write is applied, the attacker holds full administrative control of the LiteLLM proxy.
Why it matters
Full compromise of the LiteLLM proxy: an attacker with any valid low-level account can become a full administrator, exposing API keys, model configurations, spend limits, and every other tenant's data managed through the proxy.
What you can do
- Upgrade LiteLLM to 1.83.10 or later, where field-level authorization is enforced on user-update endpoints.
- Until patched, restrict or block direct calls to /user/update and /user/bulk_update to trusted admin clients only.
- Audit recent user_role changes in your LiteLLM instance and revoke any unexpected proxy_admin grants.
- Log and alert on any /user/update or /user/bulk_update request where the payload sets user_role to an administrative value, and review it for legitimate admin provisioning versus abuse.
Known benign look-alikes
- Legitimate proxy_admin provisioning a new administrator through /user/update — expected to match; review confirms intent.
- Security advisory or PR text quoting the CVE-2026-47102 payload.
- User updates that set a non-administrative role (internal_user, internal_user_viewer).