La Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) agregó el lunes una falla de alta gravedad que afecta a BerriAI LiteLLM a su catálogo de vulnerabilidades explotadas conocidas (KEV), citando evidencia de explotación activa.
Esta vulnerabilidad, registrada como CVE-2026-42271 (puntuación CVSS: 8,7), es una vulnerabilidad de inyección de comandos que podría permitir a un usuario autenticado ejecutar comandos arbitrarios en el host.
Esto afecta a las siguientes versiones del paquete LiteLLM Python:
Según la descripción de la falla compartida por BerriAI, «Dos puntos finales utilizados para obtener una vista previa de un servidor MCP antes de guardar (POST /mcp-rest/test/connection y POST /mcp-rest/test/tools/list) aceptaron la configuración completa del servidor en el cuerpo de la solicitud, incluidos los campos comando, args y env utilizados en el transporte stdio».
«Cuando se llamó con una configuración de entrada/salida estándar, el punto final intentó una conexión y generó el comando especificado como un subproceso en el host proxy con privilegios para el proceso proxy».
Los administradores de AI Gateway de código abierto y Python SDK dijeron que sus puntos finales solo están protegidos por claves API de proxy válidas, lo que podría permitir a los usuarios autenticados con claves de usuario internas privilegiadas ejecutar comandos arbitrarios en sistemas susceptibles.
Como parte del parche lanzado en la versión 1.83.7, ambos puntos finales de prueba ahora requieren que la función PROXY_ADMIN sea coherente con el punto final de almacenamiento.
LiteLLM Ejecución remota de código no autenticado a través de la omisión de validación del encabezado del host Starlette
La semana pasada, Horizon3.ai encadenó CVE-2026-42271 con CVE-2026-48710 (puntuación CVSS: 6,5) para encadenar la vulnerabilidad de omisión de validación del encabezado del host «BadHost» que afecta a Starlette, un marco ligero de interfaz de puerta de enlace de servidor asíncrono (ASGI), que evita por completo la autenticación y el acceso remoto para implementaciones vulnerables de LiteLLM. Anunciamos que hemos logrado la ejecución del código.
«CVE-2026-48710 se puede utilizar para omitir completamente el mecanismo de autenticación en implementaciones LiteLLM donde el árbol de dependencia incluye las versiones 1.0.0 y anteriores de Starlette», dijo Horizon3.ai. «Esto convierte esta vulnerabilidad en una ejecución remota de código no autenticado que no requiere credenciales».
Una utilización exitosa de la cadena de exploits como arma podría permitir al atacante ejecutar comandos arbitrarios en el host LiteLLM, acceder a las credenciales del proveedor del modelo, desviar claves API o secretos almacenados en el proxy, moverse lateralmente a la infraestructura de IA conectada o comprometer los sistemas posteriores integrados con la puerta de enlace.
Según Horizon3.ai, esta cadena de vulnerabilidades tiene una puntuación CVSS total de 10,0, que es de naturaleza crítica.
En este momento, no hay información sobre cómo se está explotando esta vulnerabilidad, la identidad de los atacantes detrás de ella, quiénes son el objetivo, qué tan extendidos están estos ataques o si alguna instancia se ha visto comprometida como resultado de su actividad. Tampoco está claro si los ataques observados en la naturaleza utilizan cadenas de exploits.
Se recomienda a los usuarios que actualicen LiteLLM a la versión 1.83.7 o posterior y Starlette a la versión 1.0.1 o posterior. Si no es posible aplicar parches de inmediato, recomendamos las siguientes mitigaciones:
Bloquee POST /mcp-rest/test/connection y POST /mcp-rest/test/tools/list en su proxy inverso o puerta de enlace API. Restrinja el acceso a la red a segmentos confiables. Rotar las credenciales almacenadas por el proxy. Verifique los registros para detectar actividad inusual en el encabezado del host y eventos de ejecución de subprocesos.
Este desarrollo se produce poco más de un mes después de que una falla crítica de inyección SQL en LiteLLM (CVE-2026-42208, puntuación CVSS: 9.3) fuera explotada activamente dentro de las 36 horas posteriores a que el error se hiciera público.
Source link
