LMCache CVE-2026-105192: cómo un socket ZeroMQ sin autenticación permite ejecutar código en tu servidor de inferencia (sin parche)

JFrog publicó el 7 de octubre de 2026 una vulnerabilidad crítica (CVSS 9.8) en LMCache, la caché de pares clave-valor que acelera servidores de inferencia como vLLM: un solo mensaje de red sin autenticación basta para ejecutar código, y todavía no existe una versión corregida.

Qué es LMCache y por qué importa

LMCache es software open source que guarda y reutiliza la caché KV de los modelos de lenguaje para que motores de inferencia como vLLM no recalculen contexto que ya procesaron. Se usa en despliegues propios de LLMs donde varios procesos o nodos comparten esa caché. Es infraestructura "invisible": no es el modelo ni la aplicación, pero corre con acceso a GPUs, modelos y, a menudo, datos de clientes.

Cómo funciona la falla (CVE-2026-105192)

Según el aviso de JFrog Security Research (descubierta por Yuval Moravchick), el modo multiproceso de LMCache abre un socket ZeroMQ de tipo ROUTER, por defecto en el puerto 5555, sin ningún mecanismo de autenticación. Los mensajes viajan en msgpack, y una extensión del formato (código 1) llama a pickle.loads sobre los datos recibidos. Como esa deserialización ocurre mientras el servidor aún está decodificando el mensaje, el código del atacante se ejecuta antes de que cualquier lógica de validación corra.

Pickle es un formato de Python que puede reconstruir objetos arbitrarios, incluidos los que ejecutan comandos al cargarse; por eso deserializar pickle de una fuente no confiable equivale a darle una shell al emisor. Según JFrog, las imágenes de contenedor oficiales ejecutan el proceso como root, lo que agrava el impacto.

Cuándo estás realmente expuesto

Por defecto el servidor multiproceso escucha solo en la máquina local, así que otro host no puede alcanzarlo. La exposición aparece cuando alguien lo arranca con una dirección enrutable, algo que según The Hacker News el propio ejemplo de despliegue en Kubernetes de LMCache hace para compartir caché entre nodos. Es decir: la configuración "multi-nodo" que muchos equipos copian de la documentación es justo la vulnerable.

Qué hacer hoy

JFrog recomienda no asignar al servidor multiproceso una dirección enrutable y mantener su puerto en localhost o en una red de clúster de confianza. Las reglas de firewall reducen el riesgo pero no lo eliminan. La solución de fondo, dice JFrog, es reemplazar pickle por un formato seguro y autenticar el transporte (CURVE o HMAC).

• Inventaría si usas LMCache (directo o como dependencia de tu stack vLLM) y en qué modo.
• Revisa el flag --host y los manifiestos de Kubernetes: nada de 0.0.0.0 ni IPs de servicio expuestas.
• Aplica NetworkPolicies que limiten el puerto 5555 a los pods que de verdad lo necesitan.
• No corras el proceso como root si puedes evitarlo, y no le montes credenciales de nube.