Las fallas de vLLM entraron al registro CVE este 25 de octubre y dejan una tarea inmediata para quien opera servidores de IA con este motor abierto: revisar la versión instalada. Tres vulnerabilidades nuevas, con notas de 8,2, 7,7 y 7,5 sobre 10, afectan a versiones anteriores a la 0.24.0, la 0.25.0 y la 0.31.0. Una permite desviar conexiones internas y filtrar datos entre tarjetas gráficas, otra tumba el servicio con una sola imagen y la tercera rompe el aislamiento entre clientes que comparten el mismo motor. El arreglo existe y es el de siempre en este programa: actualizar.
vLLM es el motor de inferencia de código abierto que más se usa para servir modelos grandes de lenguaje en producción. Empresas, universidades y nubes pequeñas lo instalan en servidores con tarjetas gráficas caras y lo comparten entre varios equipos o clientes, porque una sola GPU rinde para muchas conversaciones a la vez. Ese reparto es justo el punto débil de las tres fichas: dos de ellas atacan la convivencia entre inquilinos del mismo motor, y la tercera abre una puerta hacia la red interna donde viven esos servidores.
La nota 8,2 desvía conexiones y filtra datos entre GPU
La ficha CVE-2026-116176, clasificada como falsificación de solicitudes del lado del servidor (SSRF, por sus siglas en inglés) con nota 8,2, afecta a las versiones desde la 0.9.2 hasta antes de la 0.24.0. El truco cabe en una cabecera de la petición: quien llama a la API puede esconder una dirección de decodificación dentro del campo X-Request-Id. Al leerla, el trabajador de prefill, el proceso que prepara la primera parte de cada respuesta, se conecta por ZeroMQ al equipo del atacante si el despliegue usa el conector P2pNcclConnector, pensado para repartir trabajo entre varias GPU.
Esa conexión forzada tiene dos efectos documentados en la ficha. El primero filtra el identificador único de NCCL, la biblioteca de NVIDIA que coordina la comunicación entre tarjetas gráficas, y tensores de la caché KV, la memoria donde el motor guarda el contexto de las conversaciones en curso. El segundo efecto es más simple: el trabajador queda bloqueado y deja de atender peticiones legítimas. En un centro de datos, una cabecera manipulada termina tocando la parte más delicada de la instalación, la conversación entre máquinas.
Una imagen preparada agota la memoria del motor
La ficha CVE-2026-116177, con nota 7,5, afecta a las versiones desde la 0.10.2 hasta antes de la 0.25.0 y no pide credenciales. Los procesadores Nemotron-VL, encargados de atender modelos que reciben imágenes, fijan el límite global de píxeles Image.MAX_IMAGE_PIXELS en «sin límite». Con ese freno quitado, una imagen bomba de descompresión, un archivo pequeño que al abrirse ocupa una cantidad enorme de memoria, enviada al punto de conexión /v1/chat/completions, agota la memoria del trabajador. El sistema lo mata por falta de memoria y el servicio cae para los demás clientes del mismo motor.
La tercera ficha, CVE-2026-116180, con nota 7,7, cubre el rango más amplio: desde la 0.8.5 hasta antes de la 0.31.0. El problema nace en los tensores de logprobs sin inicializar. Los logprobs son las probabilidades que el modelo asigna a cada pieza de texto que genera, un dato que muchas aplicaciones piden para medir confianza. Una indexación de arreglos sin verificar bien esos valores permite a un cliente provocar la caída del servicio que comparten los demás. Las tres fichas llegaron al registro el mismo día, el 25 de octubre, y ninguna registra explotación activa ni código de ataque público.
Versiones corregidas y revisión de cada despliegue
Cada una de estas fallas de vLLM tiene su versión de corte: la 0.24.0 cierra la primera, la 0.25.0 la segunda y la 0.31.0 la tercera. Quien administre estos servidores gana poco parcheando al mínimo: la lectura práctica de las tres fichas es pasar directo a la versión más reciente del proyecto y confirmar que ningún nodo quedó rezagado. Las fichas tampoco aparecen en el catálogo de vulnerabilidades explotadas de la Agencia de Ciberseguridad y Seguridad de Infraestructuras de Estados Unidos (CISA), un dato que da margen, pero no excusa para dejar la revisión para la semana próxima.
El patrón de fondo lo describió la auditoría de código de X41 D-Sec, encargada por el fondo OSTIF y reexaminada en septiembre contra la versión 0.29.0: de cinco hallazgos de gravedad alta, tres quedaron corregidos por completo y dos a medias, con controles pensados para redes internas de confianza que el operador debe activar. Un conteo publicado en DEV Community sumó más de 30 avisos del proyecto entre el 12 de septiembre y el 9 de octubre, buena parte sin identificador CVE, invisibles para los escáneres que se alimentan de esas bases de datos. El motor se mueve rápido y las herramientas de aviso no siempre lo siguen.
Para el lector que contrata IA como servicio, la pregunta útil es otra: qué versión de vLLM corre detrás de la API que paga. Los proveedores que sirven modelos abiertos en servidores de IA con este motor y siguen en ramas viejas cargan con las tres fallas a la vez, y la ficha de la imagen bomba ni siquiera exige una cuenta válida para tumbar el servicio. El registro CVE dirá en los próximos días si aparece la primera prueba de concepto pública; hasta ese momento, la ventana de riesgo la define cada operador con su decisión de actualizar o esperar.
Fuente: TheHackerWire
Foto: vLLM vía GitHub
La entrada Fallas de vLLM dejan expuestos servidores de IA se publicó primero en Tecnología Geek.