CVE-2026-47102: 
NixOS Schwachstellenanalyse und -minderung

CVE-2026-47102 is a privilege escalation vulnerability in BerriAI LiteLLM affecting all versions prior to 1.83.10. The /user/update endpoint correctly restricts users to modifying only their own account but fails to restrict which fields may be changed, allowing any authenticated user to set their user_role to proxy_admin and gain full administrative access. Users with the org_admin role can exploit this directly without chaining any additional flaw, while internal_user accounts can exploit it via a secondary path through the /key/generate endpoint. It was disclosed on May 21, 2026, with a CVSS v3.1 base score of 8.8 (High) (GitHub Advisory, VulnCheck).

The vulnerability is classified as CWE-863 (Incorrect Authorization) and stems from two compounding flaws. First, the /user/update endpoint's authorization check (can_user_call_user_update) only validates that a user is updating their own account by matching user_id, but applies no field-level restrictions — the user_role field from the request body passes through _update_internal_user_params() and is written directly to the database without any privilege check. Second, the /key/generate endpoint allows internal_user accounts to create virtual API keys with arbitrary allowed_routes (including admin-only routes like /user/update) because the _is_allowed_to_make_key_request() function only validates user_id ownership and never validates that specified routes fall within the caller's role-based permissions. When such a key is used, the route check in non_proxy_admin_allowed_routes_check() treats the key's allowed_routes as an independent grant rather than a subset restriction, bypassing role-based access control entirely (Researcher Gist, LiteLLM PR #25541).

Successful exploitation grants an attacker full proxy_admin privileges over the LiteLLM deployment, including unrestricted access to all users, teams, API keys, AI models, and complete prompt history. An attacker can create, modify, or delete any user account or API key, pivot to connected AI model backends, and exfiltrate sensitive data including all historical prompts processed by the proxy. The integrity and confidentiality of the entire LiteLLM instance are fully compromised, and availability may also be impacted through administrative actions such as key deletion or model reconfiguration (GitHub Advisory, Researcher Gist).

1. Reconnaissance: Identify internet-facing LiteLLM proxy instances running versions prior to 1.83.10. Obtain or register a low-privilege internal_user account on the target instance.

2. Generate a privileged key (internal_user path): Authenticate as internal_user and call /key/generate with allowed_routes: ["/user/update"] in the request body. The endpoint stores this without validating that /user/update exceeds the caller's role permissions:

curl -X POST https://<litellm-host>/key/generate \
  -H "Authorization: Bearer <internal_user_key>" \
  -H "Content-Type: application/json" \
  -d '{"allowed_routes": ["/user/update"]}'

3. Escalate role to proxy_admin: Use the newly generated key to call /user/update, setting user_role to proxy_admin for the attacker's own user_id:

curl -X POST https://<litellm-host>/user/update \
  -H "Authorization: Bearer <new_key>" \
  -H "Content-Type: application/json" \
  -d '{"user_id": "<attacker_user_id>", "user_role": "proxy_admin"}'

4. Direct exploitation (org_admin path): If the attacker already holds org_admin role, they have legitimate access to /user/update and can skip steps 2–3, directly sending the role escalation request with their existing credentials.

5. Verify and abuse admin access: Confirm escalation by calling /user/list or /user/info with the original credentials. As proxy_admin, the attacker can now manage all users, teams, API keys, models, and access full prompt history (Researcher Gist, PoC GitHub).

• Network/API Logs: POST requests to /user/update from non-admin user accounts containing "user_role" in the request body; POST requests to /key/generate with allowed_routes containing admin-only paths such as /user/update, /user/list, or /team/list.
• Application Logs: HTTP 200 responses to /user/update requests where the caller's prior role was internal_user or org_admin; sudden appearance of new proxy_admin accounts not created by existing administrators.
• Database: Unexpected changes to the user_role field in the LiteLLM_UserTable for non-admin accounts; entries in LiteLLM_VerificationToken with allowed_routes containing management or admin-only endpoints.
• Behavioral: Unusual administrative actions (bulk user modifications, key deletions, model changes) performed by accounts that were recently non-admin; access to /user/list, /team/list, or /key/list endpoints by accounts with no prior admin history (Researcher Gist, GitHub Advisory).

Upgrade LiteLLM to version 1.83.10 or later, which introduces field-level authorization checks that restrict user_role modifications in /user/update and /user/bulk_update to proxy_admin callers only, and extends admin-only guards to the spend field in /key/update (LiteLLM v1.83.10 Release, LiteLLM PR #25541). Until patching is complete, restrict network access to the LiteLLM management API to trusted internal networks only, and audit all existing user accounts for unexpected proxy_admin role assignments. Review LiteLLM_VerificationToken entries for keys with allowed_routes containing admin-only endpoints and revoke any suspicious keys.

The vulnerability was covered by The Hacker Wire shortly after disclosure (The Hacker Wire) and appeared in a CISA vulnerability bulletin (SB26-145). The researcher who discovered the vulnerability published a detailed technical write-up on GitHub Gist, including a PoC video demonstrating the full attack chain (Researcher Gist). Community tracking on platforms such as VulnDB and threat radar services noted the vulnerability shortly after publication, and exploit-intel.com confirmed active exploitation reporting.