Tu clúster de inferencia de LLM está escuchando en el puerto 5555, y cualquier cosa en esa red puede ejecutar código como root
Hace dos semanas, el equipo de seguridad de JFrog divulgó una vulnerabilidad con una puntuación CVSS de 9.8, la segunda calificación más alta posible. Sin parche. Un exploit de prueba de concepto público. Y el software afectado se encuentra directamente en la capa de inferencia de una de las pilas de servicio de LLM de código abierto más populares del mundo.
La vulnerabilidad es CVE-2026-105192, y está en LMCache: la capa de caché distribuida de clave-valor que impulsa a vLLM, el motor de inferencia de código abierto que se ejecuta en miles de clústeres de producción ahora mismo.
No es un fallo teórico. Es una ruta de ejecución remota de código sin autenticación, divulgada el 7 de octubre de 2026 bajo el aviso JFSA-2026-001694382, y a la fecha de este artículo, no existe ninguna versión corregida.
Qué hace realmente LMCache, y por qué está en todas partes
Si ejecutas inferencia de LLM a escala, es probable que ya te hayas cruzado con LMCache. Es una caché distribuida de clave-valor que almacena y reutiliza bloques de caché KV (los estados de atención intermedios que dominan la memoria y la latencia de la inferencia de LLM). vLLM, el motor de inferencia que organizaciones desde Hugging Face hasta empresas de Oriente Medio usan para servir modelos de pesos abiertos y ajustados, integra LMCache como su capa de caché externa en despliegues multinodo.
La idea: cuando un proceso trabajador en el nodo A calcula un bloque KV, puede compartirlo con procesos trabajadores en el nodo B en lugar de volver a calcularlo. En modo distribuido, LMCache abre un socket ZeroMQ ROUTER, por defecto en el puerto 5555, para que los procesos trabajadores puedan registrarse e intercambiar bloques de caché entre máquinas.
Es una vía rápida para el servicio de LLM. Y no tiene ninguna autenticación.
La vulnerabilidad: un mensaje de caché que ejecuta tu código
Este es el fallo, desglosado:
- El transporte multiproceso de LMCache habla MessagePack con el código de extensión 1 para
DeviceIPCWrapper - Durante la decodificación, el enlace de extensión en
lmcache/v1/multiprocess/custom_types.pyreenvía los datos incrustados aDeviceIPCWrapper.Deserialize - Esa función llama a
pickle.loads, la deserialización binaria insegura de Python - La deserialización ocurre mientras el servidor procesa los argumentos de
REGISTER_KV_CACHE, antes de que se ejecute el manejador de la solicitud
En otras palabras: cualquier mensaje que llegue al servidor de caché en el puerto 5555 puede desencadenar la ejecución de código en el host, ejecutándose como el usuario que sea que esté ejecutando el proceso de LMCache.
El PoC público del propio JFrog (research.jfrog.com) lo demuestra de principio a fin:
- Un atacante envía un mensaje MessagePack multiparte manipulado al puerto 5555 en cualquier nodo de LMCache accesible
- La carga útil de pickle incrustada incluye un objeto
DeviceIPCWrappermalicioso - Cuando el servidor la deserializa, la reconstrucción de pickle ejecuta un comando del sistema operativo
- El PoC escribe la salida de
iden/tmp/zmq_pwn - El servidor luego registra un error de tipo: el manejador recibe el valor de retorno del comando en lugar del objeto wrapper esperado. Demasiado tarde.
El PoC confirma la ejecución. El contenedor se ejecuta como root.
Quién está afectado
La ruta de decodificación vulnerable se introdujo en LMCache 0.3.9 y sigue presente en todas las versiones hasta la 0.5.5, en todos los candidatos de versión hasta la 0.5.6rc3 y en la rama de desarrollo revisada al 7 de octubre. Eso significa:
- Cualquier despliegue distribuido de vLLM + LMCache en las versiones 0.3.9 hasta 0.5.6rc3
- Los despliegues que usan el flag
--hostpara enlazarse a una IP enrutable (no solo localhost) - Los clústeres de producción en configuraciones multigpu o multinodo donde los nodos de caché son accesibles por red
JFrog acotó explícitamente la puntuación de 9.8 a la configuración accesible por red. Un despliegue de vLLM en un solo host donde LMCache no abre el puerto afectado no es vulnerable. Pero si has habilitado la inferencia multinodo con direcciones enrutables, y la mayoría de los clústeres de LLM del mundo real lo han hecho, estás dentro del alcance.
Qué deberías hacer ahora mismo
No hay una versión parcheada. Este es el manual de mitigación:
- Restringir el puerto 5555: aplica reglas de firewall para asegurarte de que solo las IP específicas de los nodos de caché de tu clúster de LLM puedan alcanzar el puerto 5555. Bloquea todo lo demás.
- Volver al enlace en localhost: si puedes reconfigurar temporalmente tu despliegue para usar LMCache solo en localhost, hazlo. Pierdes el uso compartido de caché entre nodos, pero eliminas la superficie de ataque por completo.
- Reemplazar pickle por un serializador seguro: la recomendación a largo plazo de JFrog es reemplazar la deserialización de red basada en pickle por un formato de serialización seguro (el sistema de tipos nativo de MessagePack, JSON o protobuf) y autenticar el transporte ZeroMQ con CURVE, ZAP o verificación HMAC por mensaje.
- Fijar las versiones de LMCache y monitorear: si estás en 0.5.x, monitorea el rastreador de versiones en busca de una versión corregida. Hasta que llegue, las mitigaciones anteriores son tu única defensa.
- Auditar la topología de tu clúster: revisa qué nodos tienen LMCache ejecutándose con un flag
--hostenrutable. Cada uno de ellos es un posible endpoint de RCE sin autenticación para cualquier cosa que pueda alcanzar el puerto 5555 en la red interna.
El panorama general: la infraestructura de IA es ahora tu superficie de ataque
LMCache CVE-2026-105192 no es la primera vulnerabilidad crítica sin parche en la pila de servicio de IA, pero es una de las más trascendentales debido a la ubicuidad de este software. Los motores de inferencia de código abierto como vLLM se han convertido en componentes portantes en despliegues de LLM de producción en toda la región, y sus cadenas de dependencias, incluidas las capas de caché, los tokenizadores y las herramientas de orquestación, se han movido más rápido que la revisión de seguridad.
Para la región del CCG, donde las iniciativas de IA soberana y los despliegues empresariales de LLM se están acelerando, esto es un recordatorio de que la "seguridad de la infraestructura de IA" ya no es una preocupación de nicho. Los modelos son solo la capa de cómputo. La superficie de ataque real es todo lo que los rodea: la caché, el orquestador, el contenedor, la red.
En aratech, hemos estado construyendo el motor de contexto y los bucles operativos que se asientan justo sobre este tipo de infraestructura. Pensamos en términos de qué se puede alcanzar, quién puede alcanzarlo y qué ocurre cuando llega un mensaje no confiable al puerto 5555 sin las credenciales de nadie adjuntas.
Esa es la mentalidad que todo equipo que ejecute inferencia de LLM a escala debería estar considerando ahora mismo.