La vulnerabilidad crítica CVE-2026-105192 en LMCache, utilizado para acelerar servidores de grandes modelos de lenguaje como vLLM, permite a un atacante remoto no autenticado ejecutar código arbitrario en el servidor de caché cuando está habilitado el modo multiproceso, no existe parche por el momento; las organizaciones que usen LMCache con acceso de red al socket ZeroMQ deben trasladarlo de inmediato a un segmento local o de confianza y revisar las configuraciones de los despliegues en Kubernetes.
Detalles técnicos de la vulnerabilidad
La vulnerabilidad CVE-2026-105192 afecta a LMCache desde la versión 0.3.9 hasta la estable 0.5.5, así como a los candidatos de versión 0.5.6 y la rama de desarrollo actual. La descripción del CVE se ha publicado en la base CVE (ficha CVE-2026-105192), el registro formal en NVD puede estar disponible con la plantilla NVD CVE-2026-105192, y el análisis técnico se presenta en el aviso de seguridad de JFrog (JFrog JFSA-2026-001694382).
Puntos técnicos clave:
- La vulnerabilidad se manifiesta en el multiprocess mode de LMCache, donde la caché funciona como un servidor separado y los procesos de trabajo del LLM se conectan a él mediante la biblioteca ZeroMQ. El modo está descrito en la documentación oficial de LMCache: multiprocess mode.
- El servidor LMCache escucha solo localhost de forma predeterminada. El riesgo aparece cuando el operador especifica explícitamente una dirección enrutable (por ejemplo, en un clúster entre nodos), haciendo que el socket ZeroMQ sea accesible desde la red.
- En el modo multiproceso existe un tipo de mensaje que en el lado del servidor se deserializa mediante el mecanismo pickle de Python antes de verificar el tipo de mensaje. El código correspondiente puede verse en el repositorio de LMCache (ipc_wrapper.py).
- Dado que:
- en el socket ZeroMQ no hay autenticación;
- el formato pickle permite la ejecución de código arbitrario en el proceso de deserialización;
- la comprobación del tipo de mensaje se realiza después de desempaquetar los datos, —
cualquier cliente remoto capaz de establecer conexión con ese socket puede enviar un mensaje especialmente diseñado y lograr la ejecución de su propio código con los privilegios del proceso LMCache.
- Según JFrog, en las imágenes de contenedor oficiales de LMCache el proceso de caché se ejecuta con privilegios de root, lo que amplifica el problema de deserialización hasta un compromiso completo del nodo.
Una particularidad de la configuración agrava el riesgo: en el ejemplo oficial de despliegue en Kubernetes del servidor multiproceso de LMCache (lmcache-daemonset.yaml) el servidor está configurado para escuchar todas las interfaces de red, y no solo localhost. Este tipo de ejemplo suele copiarse sin cambios a clústeres de producción, lo que hace más probable la exposición.
Los desarrolladores de LMCache aún no han publicado un aviso de seguridad oficial en la sección security advisories, y no existe una versión corregida. En el material original no se registran casos de explotación de la vulnerabilidad «in the wild», pero el vector de ataque es trivial, no requiere autenticación y no está vinculado a una versión específica de Python o ZeroMQ, lo que hace que la explotación práctica sea extremadamente realista.
Contexto de amenazas: patrón repetido ShadowMQ
Los investigadores de JFrog señalan que el error lógico coincide con una serie de vulnerabilidades encontradas anteriormente en la infraestructura de inferencia de IA, que recibieron el nombre convencional de ShadowMQ: los datos de un socket de red no autenticado se envían directamente a deserialización mediante pickle. No se trata de un error aislado de un proyecto concreto, sino de un anti‑patrón persistente en el diseño de componentes de IPC y red de alto rendimiento en el stack de IA.
Es significativo que LMCache no sea el único componente de la cadena. En el ecosistema de vLLM ya se ha corregido una vulnerabilidad independiente de denegación de servicio CVE-2026-105756, en la que una única petición con un valor incorrecto de cache_salt podía hacer que el motor terminara de forma abrupta al usar el conector multiproceso de LMCache. Los detalles están disponibles en el aviso de seguridad del proyecto vLLM (GHSA-2823-qmq8-rwvj). Allí solo se trata de la caída del proceso, y no de ejecución de código, pero en conjunto esto subraya que la combinación motor LLM + caché + comunicación entre procesos se ha convertido en una nueva superficie de ataque.
Tickets adicionales en el repositorio de GitHub de LMCache (por ejemplo, issue #5507 y issue #5508) describen posibles problemas de acceso no autenticado a los datos de la caché y a comandos de diversos servicios de red, pero aún no han sido confirmados por los mantenedores, no tienen CVE ni correcciones. Para la evaluación práctica de riesgos, conviene tenerlos en cuenta como indicador del estado general del modelo de confianza del producto, y no como vulnerabilidades formalmente verificadas.
Evaluación del impacto en las organizaciones
El riesgo más alto se da en entornos donde coinciden los siguientes factores:
- uso de LMCache en multiprocess mode con accesibilidad de red al socket ZeroMQ desde otros hosts (incluidos los clústeres multi-node);
- arquitectura de microservicios o Kubernetes desplegada según el ejemplo oficial de daemonset, con el servidor vinculado a «todas las interfaces»;
- ejecución del contenedor LMCache con privilegios de root o con acceso a volúmenes compartidos que contengan tokens de acceso, configuraciones del motor LLM, registros de peticiones de usuarios.
Posibles consecuencias de una explotación exitosa:
- Acceso de compromiso total al nodo con LMCache: instalación de backdoors, criptominería, uso del nodo como punto de apoyo para posteriores movimientos laterales (lateral movement).
- Compromiso de datos confidenciales:
- acceso al contenido de la caché (fragmentos de prompts, respuestas de modelos, representaciones intermedias);
- acceso al sistema de archivos del contenedor/nodo con posible exposición de secretos del orquestador y de la plataforma LLM.
- Interrupción de la disponibilidad de los servicios de IA: comandos arbitrarios pueden detener procesos, consumir recursos, modificar la configuración o usar la caché como canal para ataques posteriores.
Las mayores amenazas afectan a:
- proveedores de servicios LLM y plataformas internas de IA con modelo multi-tenant;
- nubes y grandes clústeres donde la caché se comparte entre nodos y es posible la intersección de dominios de confianza de red;
- cualquier entorno donde LMCache esté desplegado sin una segmentación estricta de red (redes de clúster compartidas, acceso desde servicios auxiliares, namespaces de desarrollo, etc.).
Recomendaciones prácticas de protección
1. Priorización inmediata y cambio de la exposición de red
- Identifique todos los despliegues de LMCache:
- por dependencias de la plataforma LLM (por ejemplo, vLLM),
- por imágenes en el registro de contenedores que contengan el nombre
lmcache, - por configuraciones de Kubernetes que usen el ejemplo de daemonset del repositorio oficial.
- Para todas las instancias del servidor multiproceso:
- limite la dirección en la que escucha a localhost o a subredes estrictamente confiables del clúster;
- elimine la posibilidad de conexión desde segmentos de usuario, zonas VPN de uso general e internet.
- Use políticas de red de Kubernetes, grupos de seguridad separados o cortafuegos para minimizar el conjunto de hosts con acceso al socket ZeroMQ. Al hacerlo, debe asumirse que: cualquier host con acceso de red es capaz de realizar RCE.
2. Reducción de privilegios y control estricto en tiempo de ejecución
- Vuelva a compilar o redefina los contenedores de LMCache para que el proceso no se ejecute como root:
- defina un usuario sin privilegios en el Dockerfile o en el PodSpec;
- desactive capabilities innecesarias del kernel y el acceso a volúmenes hostPath.
- Active el control de comportamiento de los contenedores (seccomp, AppArmor u otros mecanismos similares) para limitar las llamadas al sistema y dificultar la post-explotación.
3. Parches y versiones de componentes relacionados
- Actualice vLLM a la versión 0.30.0 o posterior para eliminar la vulnerabilidad de DoS CVE-2026-105756 en el conector de LMCache (advisory vLLM).
- Esté atento a la publicación de una versión corregida de LMCache en la sección security advisories y en la documentación de multiprocess mode; planifique una actualización acelerada en cuanto el parche esté disponible.
4. Monitorización e indicadores de posible explotación
JFrog no publica indicadores de compromiso explícitos (direcciones IP, hashes de imágenes maliciosas, etc.), pero se pueden tomar las siguientes medidas:
- Analizar los registros de red y de Kubernetes en busca de:
- conexiones al puerto del servidor multiproceso de LMCache desde subredes o namespaces atípicos;
- un aumento anómalo del número de registros de workers o reinicios inesperados de pods con LMCache.
- Comprobar los nodos donde se ejecuta LMCache para detectar:
- la presencia de procesos y tareas cron desconocidos;
- cambios en las imágenes de contenedores, volúmenes con configuración y binarios.
- Habilitar auditoría adicional de comandos y llamadas al sistema de los contenedores de LMCache hasta que se publique la corrección oficial.
Conclusión crítica: hasta que aparezca un parche para CVE-2026-105192, la única protección real sigue siendo la restricción estricta del acceso de red al servidor multiproceso de LMCache y evitar su ejecución con privilegios de root; el primer paso debe ser el inventario de todos los despliegues de LMCache y la reconexión inmediata del socket ZeroMQ a segmentos de red locales o estrictamente controlados.
