Inyección de comandos MCP en LiteLLM: CVE-2026-42271

GTIG confirma la explotación de CVE-2026-42271: claves válidas de LiteLLM ejecutaban comandos en vistas previas MCP. Actualice a 1.83.7+.^{[1], [6], [8]}

Vector CVSS

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:N/SA:N^[1]

💡 Explicación en Lenguaje Sencillo (ELI5)

Un taller permite a los visitantes probar una herramienta antes de incorporarla. El mostrador de pruebas puede poner en marcha una máquina potente del taller, así que solo un supervisor debería darle instrucciones. En las versiones vulnerables de LiteLLM, cualquier credencial aceptada podía llegar a ese mostrador. Otra vulnerabilidad de Starlette también podía confundir a un guardia que decide el acceso usando una URL reconstruida; cada límite necesita su propia corrección. En otro mostrador, un visitante puede escribir una barra o un signo de interrogación en la etiqueta de un paquete. El empleado pega ese texto al reconstruir la dirección y lo interpreta como una ruta nueva, aunque el paquete siga por el pasillo original. Esa es la confusión separada entre Host y ruta de Starlette.^{[1], [3], [5]}

Conceptos Clave y Términos

Model Context Protocol (MCP): Protocolo mediante el cual una aplicación, como una pasarela de IA, se conecta a herramientas y fuentes de datos externas. Los endpoints de vista previa de LiteLLM prueban una configuración MCP antes de guardarla.^[1]
Transporte stdio: Modo de conexión MCP que inicia un proceso hijo local e intercambia mensajes por la entrada y salida estándar. El proceso se ejecuta en el host del proxy LiteLLM con los privilegios del servicio.^{[1], [2]}
Autorización basada en roles: Comprobación del servidor que solo permite una operación a una identidad con el rol requerido. CVE-2026-42271 dejó las rutas de vista previa sin la comprobación PROXY_ADMIN que sí tenía la operación de guardado.^{[1], [2]}
CVE-2026-48710 (Starlette BadHost): Vulnerabilidad independiente de Starlette: un encabezado Host no válido podía hacer que request.url.path difiriera de la ruta usada por el enrutamiento. Horizon3 informó que esto podía eludir la autenticación basada en rutas de LiteLLM con ciertas dependencias; no forma parte de CVE-2026-42271.^{[3], [5], [4]}
Lista de comandos permitidos para MCP stdio: Conjunto de nombres base de ejecutables que LiteLLM acepta en el transporte stdio. Se comprueba al validar la configuración y de nuevo antes de crear el cliente para registros heredados. No es un sandbox, ya que los runtimes permitidos pueden interpretar los argumentos proporcionados.^[8]

Mapeos de marcos

Referencia CWE para la debilidad descrita en esta guía: CWE-78
CISA KEV — añadido el 2026-06-08 — CVE-2026-42271

Flujo de Ataque Paso a Paso

Paso 1

Compruebe la versión de LiteLLM y la exposición de las rutas

El aviso del mantenedor afecta LiteLLM >=1.74.2 y <1.83.7 y requiere una clave API válida del proxy; antes del parche, cualquier titular autenticado, incluso con una clave interna de bajo privilegio, podía acceder a las rutas de vista previa. GTIG incluye CVE-2026-42271 en su lista de explotación confirmada; para los requisitos de este CVE, siga el modelo autenticado del aviso del mantenedor.^{[1], [6]}

Paso 2

Una clave de menor privilegio alcanza una acción administrativa de vista previa

Los endpoints aceptaban una configuración MCP completa, incluidos el comando stdio, los argumentos y las variables de entorno. El servidor autenticaba la clave, pero no comprobaba el rol PROXY_ADMIN; cualquier titular autenticado podía invocar la vista previa.^[1]

Paso 3

La vista previa inicia un proceso en el host del proxy

Para probar la configuración stdio recibida, LiteLLM creaba un cliente MCP e iniciaba el proceso hijo configurado con los privilegios del servicio proxy. Esto supone ejecución de comandos en el host de la pasarela, no solo texto inseguro devuelto por un modelo de IA.^{[2], [8]}

Paso 4

Otra vulnerabilidad de Starlette puede debilitar el límite de autenticación

Horizon3 informó que CVE-2026-48710 podía hacer que la autenticación basada en rutas viera un request.url.path distinto de la ruta seleccionada por Starlette cuando había una versión afectada. Sus investigadores dijeron haber encadenado ese comportamiento con CVE-2026-42271 para eliminar el requisito de la clave API en despliegues afectados. Atribuya la cadena a los investigadores; las dos CVE tienen causas y parches distintos.^{[5], [3], [4]}

Paso 5

Corrija ambos límites y compruebe los paquetes resueltos

LiteLLM corrigió las rutas de vista previa en 1.83.7: ahora requieren PROXY_ADMIN y tools/list tiene autenticación explícita. El parche también valida la lista de comandos permitidos en solicitudes de creación/actualización y de nuevo en _create_mcp_client para detectar configuraciones heredadas. La lista no es un sandbox; los runtimes permitidos aún interpretan argumentos. Starlette corrigió por separado CVE-2026-48710 en 1.0.1; verifique las versiones resueltas y evalúe de forma independiente la cadena reportada.^{[1], [8], [4], [7]}

Paso 6

Contexto de campaña reciente (reportado el 7 de octubre de 2026)

Black Lotus Labs informó que una muestra del malware PoeLLM probablemente apuntaba a /mcp-rest/test/connection; BleepingComputer también informó de intentos de explotar CVE-2026-42271 en la campaña. El informe no demuestra que todos los hosts infectados fueran comprometidos mediante este CVE ni que todos los objetivos de LiteLLM fueran vulnerables. Tómalo como evidencia de actividad dirigida actual, no como un recuento de víctimas atribuible a esta falla.^{[9], [10]}

Análisis de Causa Raíz

El fallo de LiteLLM consistía en la falta de una comprobación de rol en las dos rutas de vista previa de MCP: cualquier clave de API válida del proxy podía invocarlas sin el rol PROXY_ADMIN. La vista previa de conexión aceptaba una configuración stdio proporcionada por el cliente y ejecutaba su comando con los privilegios del proceso del proxy. Un fallo independiente de Starlette permitía que un encabezado Host malformado hiciera que request.url.path difiriera de la ruta que Starlette había enrutado; Horizon3 informó que la validación de claves basada en la ruta podía eludirse al encadenar este comportamiento con LiteLLM. Son vulnerabilidades distintas: corrige los límites de autorización y ejecución de comandos de LiteLLM y actualiza Starlette a 1.0.1 o posterior.^{[1], [8], [3], [4], [5]}

Código Fuente: Vulnerable vs. Seguro

Este fragmento refleja el parche integrado de LiteLLM en el límite de ejecución: comprueba el nombre base del comando antes de construir el cliente stdio, de modo que los registros heredados de base de datos/configuración también pasan por la validación. El parche además valida las solicitudes de creación y actualización de servidores y restringe ambos endpoints de vista previa a PROXY_ADMIN; /test/tools/list también incorpora la dependencia explícita user_api_key_auth. La lista permitida no es un sandbox: los runtimes permitidos aún pueden interpretar sus argumentos. Mantenga la vista previa solo para administradores y ejecute el proxy con privilegios mínimos.^{[1], [2], [8]}

Fragmento de origen: Fragmento de validación del cliente stdio de LiteLLM

IMPLEMENTACIÓN VULNERABLE

# _create_mcp_client antes de añadir la protección para comandos stdio.
if server.command and server.args is not None:
    stdio_config = MCPStdioConfig(
        command=server.command,
        args=server.args,
        env=resolved_env,
    )

PARCHE SEGURO Y ROBUSTO

# _create_mcp_client: vuelve a validar los registros heredados de la base de datos/configuración.
if server.command:
    base_command = os.path.basename(server.command)
    if base_command not in MCP_STDIO_ALLOWED_COMMANDS:
        raise HTTPException(
            status_code=403,
            detail="MCP stdio command is not in the allowlist",
        )

if server.command and server.args is not None:
    stdio_config = MCPStdioConfig(
        command=server.command,
        args=server.args,
        env=resolved_env,
    )

Lista de Verificación de Seguridad para Ingeniería

✓Inventaríe los despliegues del proxy LiteLLM y confirme la versión resuelta; actualice las versiones afectadas a 1.83.7 o posterior.^{[1], [8]}
✓Inspeccione el lockfile o la imagen desplegada y confirme Starlette 1.0.1 o posterior cuando la versión resuelta de FastAPI lo permita; no fuerce una dependencia sin probarla.^{[3], [7]}
✓Hasta actualizar LiteLLM, bloquee POST /mcp-rest/test/connection y POST /mcp-rest/test/tools/list en el proxy inverso o la pasarela API, como recomienda el aviso del mantenedor.^[1]
✓Compruebe que ambas rutas requieren user_api_key_auth y rechazan cualquier rol distinto de PROXY_ADMIN antes de crear un cliente MCP.^{[1], [8]}
✓Añada pruebas que demuestren que una petición sin autenticar y una clave válida no administrativa no llegan a ninguna vista previa, mientras que una persona administradora autorizada puede usar el flujo previsto.^[8]
✓Para Starlette, pruebe el tratamiento de encabezados Host malformados y asegúrese de que el middleware de acceso use la ruta ASGI canónica o una URL validada por el framework.^{[3], [4]}
✓Examine los registros del proxy y la telemetría de procesos hijos en busca de uso inesperado de las rutas de vista previa; rote las credenciales guardadas en el proxy si la investigación apunta a un posible acceso al host.^{[1], [8]}
✓Mantenga separados los registros: CVE-2026-42271 es ejecución de comandos en LiteLLM; CVE-2026-48710 es análisis de Host y confusión de rutas en Starlette.^{[1], [3]}
✓Revise LITELLM_MCP_STDIO_EXTRA_COMMANDS en cada entorno; las entradas personalizadas amplían la frontera de confianza de los ejecutables y no hacen seguro el manejo de argumentos.^[8]

Fuentes

← AI Security Directory →