La arquitectura distribuida de LMCache contiene una vulnerabilidad crítica que puede permitir que un cliente de red sin autenticar ejecute código mediante una deserialización insegura de Python. El fallo, CVE-2026-105192, recibió una puntuación CVSS v3.1 de 9.8 CRITICAL.
JFrog, la autoridad de numeración CVE responsable del caso, publicó y actualizó el registro de la CVE el 7 de octubre de 2026. Ese mismo día, los investigadores de seguridad de la empresa también divulgaron la vulnerabilidad y atribuyeron su descubrimiento a Yuval Moravchick.
El riesgo depende de la configuración. De forma predeterminada, LMCache limita el transporte afectado a localhost, pero los operadores pueden exponerlo en una dirección accesible desde la red para despliegues con varios nodos. En el momento de la divulgación, el informe no identificaba ninguna versión corregida de LMCache ni aportaba pruebas verificadas de que se hubiera explotado el fallo en sistemas desplegados.
Un mensaje de red llega a pickle.loads antes de la autenticación
LMCache es un software de almacenamiento en caché de código abierto diseñado para acelerar sistemas que sirven modelos de lenguaje grandes, como vLLM. El componente vulnerable es su modo multiproceso, también denominado modo distribuido, en el que LMCache funciona como un servidor de caché independiente y los trabajadores se comunican con él a través de ZeroMQ.
Según el registro del programa CVE, el servidor abre un socket ZeroMQ ROUTER que los trabajadores utilizan para registrarse e intercambiar bloques de caché KV. Ese socket no autentica a los clientes.
Los mensajes se codifican con msgpack. Durante la decodificación, el código de extensión 1 se envía a DeviceIPCWrapper.Deserialize, que llama a pickle.loads con datos controlados por el emisor. Y, lo que es más importante, la deserialización se produce mientras el servidor procesa los argumentos de la solicitud, antes de que se ejecute el gestor de mensajes correspondiente.
Por tanto, un atacante que pueda acceder al transporte puede enviar un único mensaje ZeroMQ DEALER manipulado para ejecutar código con la cuenta que ejecuta LMCache. No hacen falta credenciales ni la interacción de un usuario.
El vector asignado es:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
El registro clasifica el fallo tanto como CWE-306, falta de autenticación para una función crítica, como CWE-502, deserialización de datos no confiables.
La exposición remota depende de cómo se enlace el puerto 5555
El transporte afectado utiliza el puerto 5555 de forma predeterminada. Solo escucha en localhost, salvo que el operador indique una dirección accesible desde la red mediante --host, lo que permite que se conecten trabajadores de otros nodos.
Por ello, una instalación que utilice la vinculación local predeterminada no es accesible de forma remota desde otro equipo a través de esta interfaz. La exposición cambia si el servicio se enlaza a una dirección del clúster, a todas las interfaces o a otro punto de conexión accesible desde la red.
El informe principal señala que el despliegue de ejemplo de LMCache en Kubernetes inicia el servidor en todas las interfaces de red. También indica que una instancia de LMCache integrada en un único proceso de vLLM no abre el puerto afectado.
Según la descripción de JFrog, las imágenes oficiales de contenedor de LMCache ejecutan el proceso como root. En esas imágenes, una explotación satisfactoria podría permitir ejecutar código con privilegios de root dentro del entorno en el que opera el proceso. Esto no se aplica automáticamente a las instalaciones configuradas para ejecutar LMCache con una cuenta con menos privilegios, ni demuestra a qué recursos del host puede acceder un contenedor concreto.
Los registros citados no verifican que se haya producido ninguna explotación real. La vía técnica permite la ejecución remota de código cuando se puede acceder al socket, pero eso no equivale a disponer de pruebas de que se haya producido un ataque en el mundo real.
Los registros de versiones discrepan sobre el rango completo de LMCache
La entrada oficial de la CVE indica que LMCache 0.3.9 está afectada, pero no especifica una versión límite superior. Sus referencias apuntan a código vulnerable tanto en v0.3.9 como en v0.5.5.
El artículo ofrece un rango más amplio: versiones desde la 0.3.9 hasta la 0.5.5, además de las versiones candidatas a publicación de la 0.5.6 y la rama de desarrollo. Señala que la 0.5.5 es la versión estable más reciente y que la versión 0.3.9 se publicó en octubre de 2025.
Estas afirmaciones tienen distinto alcance probatorio. El registro de la CNA confirma que la versión 0.3.9 está afectada, mientras que la cobertura más amplia de versiones y ramas procede del artículo, no de una declaración completa del rango afectado en el registro de la CVE proporcionado.
En el momento de la divulgación no se había identificado ninguna versión corregida de LMCache. El registro de la CVE no incluye una versión con la corrección y, según el artículo, el 7 de octubre de 2026 aún no había una versión corregida disponible.
El aislamiento de red es la medida defensiva inmediata
Las recomendaciones provisionales de JFrog, según las recoge el artículo, se centran en impedir que sistemas no confiables accedan al transporte ZeroMQ:
- No se debe enlazar el servidor multiproceso a una dirección accesible desde la red mientras no haya una versión corregida.
- Si no se necesita el funcionamiento distribuido, hay que mantener el servicio en localhost.
- Si los trabajadores remotos deben conectarse, hay que limitar el acceso a una red de clúster de confianza.
- Hay que aplicar controles de firewall al puerto 5555 y permitir únicamente las conexiones necesarias.
El filtrado del firewall reduce la superficie de ataque accesible, pero no elimina el comportamiento de deserialización inseguro. Cualquier equipo permitido o comprometido que pueda conectarse al socket podría seguir enviando el mensaje malicioso.
Los operadores también deben comprobar qué cuenta ejecuta el proceso de LMCache y reducir sus privilegios al mínimo. Esto limita las posibles consecuencias, pero no sustituye la corrección del código vulnerable.
El artículo indica que el aviso de JFrog no incluía un procedimiento para determinar si ya se había producido una explotación. El material citado tampoco proporciona indicadores de compromiso ni consultas forenses para CVE-2026-105192; esta observación se limita a la información disponible y no demuestra que no esistano indicazioni altrove.
Un fallo distinto de vLLM puede detener EngineCore
Un problema relacionado, pero técnicamente distinto, afecta a los despliegues de vLLM que utilizan el conector KV integrado LMCache-MP. CVE-2026-105756 permite que un valor cache_salt malformado provoque una excepción no capturada y detenga EngineCore.
La vulnerabilidad tiene una puntuación CVSS v3.1 de 6.5 y una clasificación Moderada:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Está clasificada como CWE-20, validación incorrecta de entradas, y CWE-248, excepción no capturada. A diferencia de la ejecución remota de código de LMCache, el vector registrado indica que se requieren pocos privilegios y que el impacto se limita a la disponibilidad.
Los modelos compatibles con OpenAI para Completions, Chat Completions y Responses aceptan cualquier valor cache_salt no vacío, pero IPCCacheServerKey, en LMCache-MP, impone restricciones adicionales. Rechaza las sales de más de 128 caracteres o que contengan @, /, \ o NUL.
Estas restricciones no se aplicaban antes de que el valor llegara a la búsqueda de caché del planificador. Según el aviso de seguridad de GitHub, una sal rechazada provoca un ValueError que no se captura en el conector ni en el planificador. A continuación, EngineCore trata la excepción como un error fatal e interrumpe el servicio para los usuarios que lo utilizan al mismo tiempo. El aviso incluye cache_salt="/" como ejemplo.
El problema se confirmó en vLLM 0.25.1, commit 752a3a504485, y solo afecta a los casos en que está habilitado el conector opcional LMCache-MP. Este conector requiere lmcache >= 0.4.4.
La descripción de NVD y el rango general del aviso indican que las versiones anteriores a 0.30.0 están afectadas y que la 0.30.0 corrige el problema. Sin embargo, otro campo del aviso indica que las versiones corregidas son >= 30.0.0. No se debe asumir que este valor incoherente equivale al otro; los operadores deben confirmar qué versión del paquete van a desplegar. El aviso se publicó el 23 de septiembre de 2026, y el artículo indica que vLLM 0.30.0 se publicó el 22 de septiembre.
Otras denuncias sobre LMCache siguen sin confirmarse
El artículo también describe seis denuncias de seguridad más sobre LMCache, presentadas por una cuenta de GitHub el 6 de octubre de 2026. En ellas se alega que es posible acceder a datos almacenados en caché de otros clientes y a servicios de red sin autenticar capaces de ejecutar comandos.
Las denuncias no tienen asignación de CVE ni confirmación de los responsables del proyecto, y el artículo citado no identifica ninguna corrección. Se basan en afirmaciones respaldadas por pruebas de concepto y son independientes de CVE-2026-105192.
Una de ellas sostiene que, en la versión 0.5.5, un servidor HTTP administrativo escuchaba en todas las interfaces, mientras que las versiones candidatas a publicación de la 0.5.6 lo limitan a localhost. Hasta que los responsables del proyecto validen las afirmaciones, estas denuncias no deben presentarse como vulnerabilidades confirmadas de LMCache.
El patrón inseguro que está detrás de CVE-2026-105192 se asemeja al uso de mensajes sin autenticar con Python pickle que los investigadores analizaron bajo el nombre ShadowMQ en noviembre de 2025. El artículo no demuestra que exista código compartido ni un origen común entre aquellos hallazgos y LMCache.
