CVE-2026-42271 y CVE-2026-48710: La cadena de exploits en LiteLLM que obtiene un RCE no autenticado con puntuación 10.0

• POST /mcp-rest/test/connection

• POST /mcp-rest/test/tools/list

Ambos endpoints aceptan una configuración completa de servidor MCP en el cuerpo de la petición JSON, incluyendo los campos Cmd, args y env que el transporte stdio utiliza para lanzar procesos . Cuando un usuario autenticado llama a cualquiera de estos dos endpoints, LiteLLM toma el valor proporcionado en Cmd y lo ejecuta como un subproceso en la máquina host, con los mismos privilegios del sistema operativo que el propio proceso del proxy LiteLLM .

Originalmente, BerriAI reveló esto como un fallo de ejecución remota de código que requería autenticación: un atacante necesitaba una clave API válida para llegar a los endpoints, y no existía una verificación de rol para restringir quién podía llamarlos. Cualquier usuario con una clave API de proxy, incluso con pocos privilegios, podía ejecutar comandos en el host . Pero la historia no termina aquí.

El bypass "BadHost" de Starlette que elimina la autenticación

La segunda vulnerabilidad es la CVE-2026-48710, apodada "BadHost" por los investigadores. Se trata de un fallo en la validación de la cabecera Host en Starlette, el framework ASGI ligero que sirve de base a FastAPI, vLLM y miles de otras aplicaciones web en Python, incluido LiteLLM . Todas las versiones de Starlette desde la 0.8.3 hasta la 1.0.0 están afectadas .

La causa raíz es una discrepancia entre cómo Starlette enruta las peticiones entrantes y cómo reconstruye la URL para la lógica de la aplicación . La capa de enrutamiento ASGI utiliza la ruta HTTP sin procesar de la petición para decidir qué endpoint la maneja. Pero request.url —la URL que el middleware y los decoradores de la aplicación ven— se reconstruye concatenando el valor de la cabecera Host sin procesar con la ruta, sin una validación adecuada .

Al inyectar caracteres delimitadores de autoridad-ruta de URI, como ? o #, en la cabecera Host, un atacante puede hacer que request.url.path parezca completamente diferente a la ruta real enrutada . El middleware ve una ruta inofensiva como /, mientras que el enrutador reenvía la petición al verdadero endpoint vulnerable. Cualquier middleware de autenticación basado en ruta que confíe en request.url.path puede ser burlado de forma trivial .

La cadena completa: de una gravedad 8.7 a un 10.0

El decorador de autenticación de LiteLLM verifica request.url.path para decidir si una petición necesita una clave API. El bypass "BadHost" permite a un atacante manipular esa URL para que el middleware de autenticación vea una ruta que no requiere autenticación, mientras que el enrutador ASGI envía simultáneamente la petición a uno de los endpoints vulnerables de inyección de comandos MCP .

Esto elimina la única barrera de control de acceso que se interponía entre el atacante y la ejecución de comandos. Un atacante sin credenciales y sin acceso previo a la red puede enviar una única petición HTTP maliciosa que evade la autenticación por completo y ejecuta comandos del sistema operativo en el host del proxy LiteLLM . Horizon3.ai confirmó que la cadena completa funciona y le asignó una puntuación CVSS combinada de 10.0 —la máxima gravedad— porque logra una ejecución remota de código sin autenticación .

Lo que un atacante puede hacer con este acceso

Una explotación exitosa otorga al atacante la capacidad de ejecutar comandos con los privilegios del proceso proxy de LiteLLM. A partir de ahí, la superficie de amenaza se expande rápidamente:

• Ejecución de comandos arbitrarios: Los atacantes pueden instalar puertas traseras, malware, mineros de criptomonedas o cualquier otro software que los permisos del proceso anfitrión permitan .
• Robo de credenciales a escala: El proxy LiteLLM se sitúa entre las aplicaciones y decenas de proveedores de LLM. Almacena claves API para OpenAI, Anthropic, Azure, AWS Bedrock, Google y otros servicios conectados en su base de datos o variables de entorno . Explotar esta vulnerabilidad permite a los atacantes extraer todas las credenciales almacenadas en una sola operación.
• Movimiento lateral por la infraestructura de IA: Con las claves API de la nube robadas y el acceso shell al host del proxy, los atacantes pueden pivotar hacia los servicios conectados, servidores MCP internos, bases de datos vectoriales y frameworks de agentes posteriores .
• Implicaciones para todo el ecosistema: El fallo "BadHost" de Starlette afecta a más de 400,000 proyectos dependientes, incluyendo aplicaciones FastAPI, servidores vLLM, despliegues de servidores MCP y frameworks de agentes de IA. Cualquiera de estos que use middleware de autenticación basado en ruta en versiones de Starlette anteriores a la 1.0.1 está igualmente expuesto a la evasión de autenticación .

Por qué la alerta de CISA es tan urgente

La inclusión de la CVE-2026-42271 por parte de CISA en el catálogo KEV el 8 de junio de 2026 confirma que la vulnerabilidad no es teórica: los atacantes la están utilizando activamente en este momento . Bajo la Directiva Operativa Vinculante 22-01, todas las agencias del poder ejecutivo civil federal de EE. UU. deben parchear las vulnerabilidades listadas en el KEV dentro de un plazo de corrección asignado. CISA también recomienda encarecidamente a todas las organizaciones, públicas y privadas, que traten las adiciones al KEV como prioridades de parcheo de emergencia .

Pasos para una solución inmediata

La solución para el exploit encadenado requiere actualizaciones en dos frentes, además de varias medidas de defensa en profundidad para abordar la exposición de credenciales:

1. Actualice LiteLLM a la versión 1.83.7 o posterior. Esta versión elimina la capacidad de los endpoints de prueba MCP para ejecutar comandos proporcionados por el usuario, cerrando el vector de inyección de comandos por completo .
2. Actualice Starlette a la versión 1.0.1 o posterior. El parche valida las cabeceras Host entrantes según la especificación de la URL e ignora las que contienen caracteres no válidos, evitando el truco de confusión de rutas que permite la evasión de autenticación .
3. Rote todas las credenciales almacenadas de inmediato. Asuma que cualquier clave API, token de acceso o credencial de base de datos que el proxy LiteLLM haya almacenado ha sido comprometida. Rote todas las claves de OpenAI, Anthropic, Azure, AWS y otros proveedores, y revise los paneles de facturación en busca de usos no autorizados .
4. Bloquee los endpoints en el proxy inverso o WAF. Como medida de defensa en profundidad mientras se implementan los parches, configure su proxy inverso o firewall de aplicaciones web para descartar cualquier petición a

   POST /mcp-rest/test/connection

   y

   POST /mcp-rest/test/tools/list

   antes de que lleguen a la aplicación .
5. Realice una auditoría retrospectiva de accesos no autorizados. Revise los registros del proxy LiteLLM en busca de actividad inusual en los endpoints de prueba MCP, en particular peticiones de direcciones IP inesperadas o aquellas con cabeceras Host manipuladas .

La gravedad CVSS 10.0 combinada, la explotación activa en la naturaleza y la designación KEV de CISA significan que las organizaciones que ejecutan LiteLLM o servicios basados en Starlette deben tratar esto como un evento de emergencia de parcheo y rotación de credenciales. La ventana entre la explotación activa y la exfiltración de credenciales ya está abierta.