LMCache expone vulnerabilidad de ejecución remota de código no validada en modo multiproceso, afecta la capa de caché de inferencia de modelos grandes

El 8 de octubre de 2026, iThome y JFrog Security Research publicaron simultáneamente un informe que describe una vulnerabilidad de ejecución remota de código no validada en LMCache cuando se ejecuta en modo multiproceso (distribuido). La vulnerabilidad, identificada como CVE‑2026‑105192, recibió una puntuación CVSS v3.1 de 9.8, lo que la clasifica como crítica. Este hallazgo subraya la importancia de revisar los mecanismos de autenticación en sistemas de caché distribuidos.

Resumen de la vulnerabilidad

El defecto fue divulgado por el equipo de investigación de JFrog (identificado con el número JFSA‑2026‑001694382) el 7 de octubre de 2026, y afecta a todas las versiones de LMCache a partir de la 0.3.9, incluyendo la versión estable más reciente 0.5.5, la versión de prueba 0.5.6rc3 y todas las ramas de desarrollo, ninguna de las cuales contiene una corrección. La causa raíz radica en que LMCache habilita un socket ZeroMQ ROUTER para compartir una caché KV entre procesos, escuchando por defecto en el puerto TCP 5555 y sin activar ningún mecanismo de autenticación, como CURVE, ZAP, contraseñas o HMAC.

Detalles técnicos

En una implementación con varios nodos, el usuario debe proporcionar una dirección enrutable mediante el parámetro `--host`. Al hacerlo, el socket ZeroMQ deja de estar limitado únicamente a la interfaz localhost y pasa a ser accesible desde el exterior. LMCache utiliza msgpack como formato de codificación para la transmisión de datos; el código de extensión 1 de msgpack se mapea a la función `DeviceIPCWrapper.Deserialize`. Dentro de esa función, se invoca directamente la rutina `pickle.loads` de la biblioteca estándar de Python. Esta deserialización ocurre mientras el servidor todavía está procesando los parámetros de `REGISTER_KV_CACHE`, antes de que cualquier manejador de solicitud sea activado, lo que permite que un atacante inserte una carga útil de pickle maliciosa que, al deserializarse, ejecuta código Python arbitrario en el contexto del proceso.

Proceso de ataque

El atacante solo necesita enviar un mensaje msgpack especialmente elaborado al puerto 5555 que está abierto. La carga útil de pickle incluida en el mensaje puede escribir archivos en el sistema, por ejemplo en `/tmp/zmq_pwn`, y luego provocar una salida de registro con un error de tipo, lo que sirve como evidencia de que el código se ha ejecutado dentro del contexto del proceso LMCache. La imagen oficial del contenedor lanza LMCache con privilegios de root por defecto; si el exploit tiene éxito, el atacante obtiene acceso como root dentro del contenedor y, a partir de ahí, puede comprometer otros servicios que se ejecuten en la misma máquina host.

Alcance afectado

Las versiones afectadas comprenden la serie 0.3.9, todas las versiones 0.4.x y la serie 0.5.x, y ninguna de las imágenes de contenedor oficiales ha recibido una corrección. iThome también señaló que el puerto ZeroMQ solo se habilita cuando LMCache se ejecuta como un servicio multiproceso independiente; si LMCache se utiliza únicamente dentro del proceso vLLM, el puerto no se inicia y, por lo tanto, la vulnerabilidad no queda expuesta. De forma predeterminada, ZeroMQ está vinculado únicamente a localhost, lo que impide que un atacante remoto acceda directamente, a menos que un administrador cambie manualmente el parámetro `--host` para usar una dirección que sea enrutable desde fuera.

Mitigación y recomendaciones

JFrog recomienda restringir de inmediato la dirección de enlace del servicio multiproceso a localhost y bloquear el puerto TCP 5555 mediante firewalls o políticas de red del clúster. Hasta que se disponga de un parche de seguridad, no se debe utilizar una dirección IP que pueda ser enrutada externamente en el parámetro `--host`. A largo plazo, se sugiere rediseñar la capa de transporte para evitar el uso de pickle en la deserialización de datos de red no validados, adoptando un formato de serialización seguro, y añadir mecanismos de autenticación al socket ZeroMQ, como CURVE o HMAC.

Seguimiento y perspectivas

Hasta el 8 de octubre de 2026, el proveedor no había publicado ninguna versión corregida ni una imagen de contenedor actualizada que deshabilite la deserialización insegura, y el calendario de corrección sigue sin estar definido. Tampoco está claro si las distribuciones de terceros ya han incorporado medidas de mitigación retroportadas. Los entornos que hayan mantenido la vinculación predeterminada a localhost o que hayan aislado los contenedores de redes no confiables no están expuestos a una amenaza directa de un atacante remoto; sin embargo, personal interno o sistemas que ya hayan sido comprometidos podrían seguir explotando esta vulnerabilidad para obtener privilegios máximos dentro del contenedor.