Se ha publicado un exploit de prueba de concepto (PoC) para una vulnerabilidad crítica en LMCache, identificada como CVE-2026-105192. Este fallo, que tiene una puntuación CVSS de 9.8, permite la ejecución remota de código sin autenticación en despliegues distribuidos expuestos. La vulnerabilidad afecta a las versiones de LMCache a partir de la 0.3.9 y, según JFrog Security Research, no existe una versión corregida hasta el 7 de octubre.

Se ha publicado un exploit de prueba de concepto (PoC) para una vulnerabilidad crítica en LMCache que puede permitir la ejecución remota de código (RCE) no autenticada en despliegues distribuidos expuestos.

Identificada como CVE-2026-105192, el fallo tiene una puntuación CVSS de 9.8 y afecta a las versiones de LMCache a partir de la 0.3.9. Hasta el 7 de octubre, JFrog Security Research informó que no había una versión corregida.

La vulnerabilidad, identificada por Yuval Moravchick del equipo de JFrog Security Research, existe en el modo multiproceso de LMCache, también conocido como modo distribuido.

Esta configuración de despliegue utiliza un servicio ZeroMQ (ZMQ) para que múltiples procesos trabajadores puedan registrarse y compartir bloques de caché de clave-valor. El problema se vuelve grave cuando configuras el servicio para que escuche en una dirección de red enrutable para su uso en múltiples nodos.

LMCache se utiliza comúnmente junto con sistemas de inferencia de modelos de lenguaje grandes para mejorar el rendimiento mediante el uso compartido y la reutilización de datos almacenados en caché.

Sin embargo, JFrog descubrió que su transporte ZMQ multiproceso acepta mensajes sin autenticación. El servicio no utiliza la seguridad ZeroMQ CURVE, autenticación ZAP, contraseñas ni verificación a nivel de mensaje. Esto deja el transporte abierto a cualquier persona que pueda alcanzar el puerto expuesto.

El servicio vulnerable utiliza MessagePack (msgpack) para decodificar los datos enviados a través de la conexión ZMQ. Durante este proceso, LMCache maneja una extensión personalizada de MessagePack a través de la función DeviceIPCWrapper.Deserialize. Esa función llama a pickle.loads de Python, que es inseguro cuando procesa datos recibidos de una fuente no confiable.

Los datos de Python pickle pueden contener instrucciones que ejecutan código mientras se decodifican. En este caso, un usuario remoto puede enviar un mensaje ZMQ manipulado que contenga un objeto pickle malicioso.

LMCache procesa ese objeto antes de validar el mensaje o pasarlo al manejador correspondiente. Como resultado, el código suministrado puede ejecutarse con los permisos del proceso LMCache.

PoC publicada para el fallo crítico de LMCache

La PoC de JFrog muestra que un solo mensaje ZeroMQ DEALER no autenticado enviado al puerto de servicio predeterminado, 5555, puede activar la ejecución de código.

La prueba de concepto escribe la salida de un comando en un archivo local para demostrar la ejecución exitosa. En las imágenes de contenedor oficiales de LMCache, se informa que el proceso se ejecuta como root, lo que significa que una explotación exitosa podría darle a un intruso el control a nivel de root del contenedor afectado.

El problema es más peligroso en despliegues de múltiples nodos donde LMCache se inicia con la opción --host configurada en una dirección enrutable como 0.0.0.0. En esa configuración, los sistemas remotos pueden conectarse al transporte ZMQ.

Una configuración estándar de un solo host que mantiene el escuchador vinculado a localhost no es accesible desde otras máquinas y no está expuesta de la misma manera.

JFrog afirmó que la ruta de decodificación insegura se introdujo en la versión 0.3.9 de LMCache. Sigue presente en la última versión de PyPI, la 0.5.5, así como en las versiones candidatas 0.5.6 hasta la 0.5.6rc3 y en la rama de desarrollo revisada el 7 de octubre.

El aviso indica que no se había publicado ninguna versión parcheada de LMCache en el momento de la divulgación. El fallo muestra un riesgo familiar para los entornos de IA y aprendizaje automático: servicios internos expuestos que utilizan Python pickle para datos de red.

Anteriormente se informó sobre riesgos relacionados de ejecución remota de código basados en pickle que afectaban al Llama Stack de Meta, donde las comunicaciones inseguras de ZeroMQ también permitían que objetos serializados manipulados ejecutaran código en servidores vulnerables.

Hasta que LMCache publique una corrección, debes evitar exponer el servicio multiproceso públicamente, mantenerlo en localhost siempre que sea posible o restringir el acceso a redes confiables utilizando firewalls y segmentación.

La solución a largo plazo requiere eliminar pickle.loads del manejo de datos de red no autenticados. JFrog recomendó reemplazar el serializador utilizado en la extensión MessagePack por un formato de datos seguro y añadir una autenticación de transporte fuerte, como ZeroMQ CURVE o un código de autenticación de mensajes. LMCache también debería evitar la vinculación a redes enrutables a menos que la autenticación esté habilitada explícitamente.

Si gestionas organizaciones que ejecutan LMCache en entornos de inferencia de IA distribuidos, debes revisar inmediatamente los escuchadores ZMQ expuestos, comprobar si el puerto 5555 es accesible en tu red y ejecutar los servicios de LMCache con los privilegios mínimos posibles.

La naturaleza crítica de CVE-2026-105192 proviene de la combinación del acceso a la red no autenticado, la decodificación insegura de pickle y la posibilidad de ejecución como root en los despliegues de contenedores predeterminados.

Fuentes:
https://cybersecuritynews.com/poc-lmcache-flaw/