Hackers aprovechan la vulnerabilidad LiteLLM RCE en estado salvaje para ejecutar comandos arbitrarios

Los actores de amenazas están explotando activamente una vulnerabilidad crítica encadenada en LiteLLM, un popular proxy de puerta de enlace de IA de código abierto, que permite la ejecución remota de código (RCE) no autenticada en implementaciones vulnerables. El núcleo de esta amenaza es CVE-2026-42271, una falla de inyección de comandos en los puntos finales de prueba del servidor Model Context Protocol (MCP) de LiteLLM. Al manipular el encabezado del host HTTP para aprovechar la omisión de autenticación de Starlette, los atacantes pueden eludir por completo el requisito de clave API de LiteLLM, logrando que los comandos de ejecución remota se ejecuten con los mismos privilegios del proceso proxy, sin necesidad de inicio de sesión ni credenciales.

Una vez que se logra la ejecución del código, los actores de amenazas pueden ejecutar comandos arbitrarios del sistema operativo en el host de LiteLLM, robar claves API y credenciales del proveedor de modelos almacenadas por el proxy, acceder a secretos y variables de entorno en el proceso del proxy y moverse lateralmente hacia la infraestructura de IA conectada y sistemas posteriores. Dado que LiteLLM se usa ampliamente para enrutar y administrar llamadas API a modelos de lenguaje grandes (LLM) de proveedores como OpenAI, Anthropic y Azure, un compromiso de la capa de puerta de enlace puede derivar en una exposición más amplia de la cadena de suministro de IA. Indicadores de compromiso (IoC): los equipos de seguridad deben monitorear ejecución inesperada de subprocesos originados en el proceso LiteLLM, solicitudes HTTP dirigidas a /mcp-rest/test/connection o /mcp-rest/test/tools/list, valores de encabezado Host inusuales o malformados y eventos de ejecución de comandos no autorizados en el sistema host.

Las organizaciones deben actualizar inmediatamente LiteLLM a la versión 1.83.7 o posterior y asegurarse de que Starlette esté actualizado a la versión 1.0.1 o posterior. Si los parches no se pueden aplicar de inmediato, se recomienda bloquear el acceso externo a los puntos finales de prueba MCP, restringir el acceso de red solo a segmentos confiables, rotar todas las credenciales y claves API almacenadas por el proxy y revisar los registros en busca de anomalías en encabezados Host y actividad de subprocesos. Dado que la explotación ya está activa en entornos reales, estas medidas deben tratarse como una prioridad de emergencia en cualquier implementación autohospedada de LiteLLM.

Consultar publicación original ↗