Los endpoints de prueba MCP de LiteLLM: una inyección de comandos ya bajo explotación activa

¿Qué es esto?

LiteLLM es una de las pasarelas de IA de código abierto más desplegadas: un proxy que ofrece a los consumidores internos de IA una única interfaz compatible con OpenAI frente a más de cien proveedores de modelos. Un fallo de inyección de comandos de alta gravedad, ubicado en sus endpoints de prueba del Model Context Protocol (MCP), permite que cualquier titular de una clave API del proxy ejecute comandos arbitrarios en el host de la pasarela. LiteLLM publicó la corrección en la versión 1.83.7 el 8 de mayo de 2026; todas las versiones desde la 1.74.2 hasta la 1.83.6 están afectadas.

Lo que distingue a esta vulnerabilidad del habitual goteo de CVE es su cronología. El 8 de junio de 2026, CISA la añadió a su catálogo Known Exploited Vulnerabilities (KEV) tras confirmar su explotación activa en el mundo real, aproximadamente cinco semanas después del parche. La AI Safety Initiative de la Cloud Security Alliance publicó una nota de investigación detallada el 13 de junio de 2026, y la prensa de seguridad informó de actividad de explotación que comenzó poco después del aviso. Se trata, por tanto, de una vulnerabilidad ya corregida y divulgada públicamente que se está utilizando ahora mismo contra pasarelas sin actualizar.

Cómo funciona

El fallo reside en dos endpoints añadidos para dar soporte a la integración MCP de LiteLLM: POST /mcp-rest/test/connection y POST /mcp-rest/test/tools/list. Estaban pensados para que un operador pudiera previsualizar un servidor MCP antes de guardarlo, por lo que aceptan una configuración de servidor completa directamente en el cuerpo de la petición, reflejando el transporte stdio de MCP, con los campos command, args y env que describen un subproceso a lanzar en el host del proxy.

La causa raíz combina dos omisiones: la ausencia de control de autorización (los endpoints no estaban restringidos a un rol administrativo) y el tratamiento inseguro de la configuración de proceso controlada por quien llama (sin lista de comandos permitidos, sin sandbox). Cualquier principal con una clave API válida del proxy —una credencial que suele repartirse entre equipos de desarrollo y servicios automatizados simplemente para acceder a los modelos— podía así hacer que el proxy ejecutara un comando suministrado. El fallo aislado se puntúa como CVSS 8.7; solo el requisito de la clave API lo mantuvo fuera del nivel crítico.

Ese requisito desaparece cuando el fallo se encadena. Investigadores de Horizon3.ai demostraron su combinación con el fallo de omisión de autenticación BadHost en Starlette —una desincronización de la cabecera Host que rompe la autorización basada en rutas en los servicios construidos sobre FastAPI—. Una cabecera Host falsificada elude el middleware, y la petición alcanza el endpoint MCP vulnerable sin credencial alguna, produciendo una ejecución remota de código no autenticada puntuada como CVSS 10.0.

Aquí no se reproduce ninguna cadena de explotación; el mecanismo descrito procede íntegramente de los avisos públicos.

Por qué importa

Las pasarelas de IA ocupan una posición estructuralmente privilegiada. Un despliegue de LiteLLM en producción suele guardar las claves API de cada proveedor al que sirve, las credenciales de la base de datos de registro de uso y la configuración de política que controla qué equipos acceden a qué modelos. La ejecución de código en ese host no se detiene, por tanto, en la pasarela: expone toda la superficie de credenciales concentrada tras ella, y en los despliegues de Kubernetes una cuenta de servicio con permisos excesivos puede extender el alcance hasta el plano de control del clúster.

La lección más amplia es un patrón, no un único fallo. Funcionalidades de conveniencia —un endpoint en línea para «probar este servidor MCP»— se entregaron sin los controles de autorización adecuados para un componente que centraliza todo el tráfico de IA. Es la misma clase de fallo que produjo otros problemas de LiteLLM este año, entre ellos una inyección SQL previa a la autenticación en el proxy. El middleware de IA es ya un objetivo de primer orden y merece una postura de seguridad comparable a la de los sistemas de gestión de identidades y accesos, en lugar de la de una herramienta interna de desarrollo.

Defensas

Actualice de inmediato. Lleve LiteLLM a la 1.83.7 o posterior, que restringe los endpoints de prueba MCP al rol PROXY_ADMIN, y actualice Starlette a la 1.0.1 en el mismo ciclo. Sin la actualización de Starlette, la cadena no autenticada sigue siendo explotable incluso frente a código de LiteLLM ya parcheado.

Reduzca la exposición si no puede parchear hoy. Elimine el acceso público a Internet del proxy y limite su alcanzabilidad únicamente a los servicios que realmente lo necesiten. Esto por sí solo elimina la vía externa no autenticada mientras programa la actualización.

Rote y reduzca las credenciales. Trate como potencialmente comprometida cualquier pasarela que haya ejecutado una versión vulnerable: rote todas las claves API de proveedor que guardara el proxy y revoque las claves API del proxy repartidas a usuarios o servicios sin una necesidad activa. Menos titulares de claves significa menos principales capaces de disparar el fallo incluso sin la omisión de la cabecera Host.

Busque señales de compromiso. Revise procesos inesperados lanzados por la cuenta de servicio de LiteLLM, archivos nuevos en directorios cron o systemd, conexiones salientes inusuales desde el host del proxy y cambios inexplicables en las variables de entorno o en la base de datos de LiteLLM.

Corrija la clase, no solo el CVE. Imponga control de acceso basado en roles en cada operación administrativa en lugar de un modelo plano de clave API, segmente el middleware de IA en su propio plano de red y audite el ecosistema Starlette en general —servicios FastAPI, servidores vLLM, frameworks MCP— por la misma omisión de la cabecera Host, con independencia de cualquier exposición directa a LiteLLM.

Estado

Elemento	Referencia	Fecha	Notas
Inyección de comandos aislada	CVE-2026-42271 (NVD)	divulgada en 2026	CVSS 8.7; endpoints de prueba MCP, cualquier clave API del proxy
Versión corregida	LiteLLM 1.83.7	2026-05-08	Endpoints restringidos a PROXY_ADMIN; Starlette actualizado a 1.0.1
RCE no autenticada encadenada	con CVE-2026-48710 (BadHost)	2026	CVSS 10.0; omisión de autenticación por cabecera Host en Starlette
Inclusión en el KEV de CISA	Catálogo KEV de CISA	2026-06-08	Explotación activa confirmada
Nota de investigación CSA	Cloud Security Alliance	2026-06-13	Análisis de la superficie de credenciales de las pasarelas de IA
Versiones afectadas	LiteLLM 1.74.2 → 1.83.6	—	Actualizar a 1.83.7+

La conclusión para los equipos técnicos: una pasarela de IA concentra las credenciales de todo lo que sirve, así que un endpoint de conveniencia colocado sobre ella nunca es de bajo riesgo. Actualice a la 1.83.7 y a Starlette 1.0.1, retire el proxy de Internet, rote las claves que guardaba y trate el middleware de IA con el mismo rigor que aplica a sus sistemas de identidad.