Lo que dice el aviso
El proyecto vLLM reveló que CVE-2026-22778 / GHSA-4r2x-xpjr-7cvv es una cadena de vulnerabilidad crítica en el procesamiento de video. El aviso revisado dice que una implementación afectada puede alcanzar la ejecución remota de código cuando sirve un modelo con capacidad de video y procesa la entrada de video controlada por el atacante. Las implementaciones que no ofrecen un modelo de video no se ven afectadas por este aviso. [S1] [S2]
Lanzamientos afectados
Las versiones de PyPI afectadas comienzan en vLLM 0.8.3 y finalizan antes de 0.14.1. PyPA y OSV enumeran las versiones publicadas afectadas, incluidas las publicaciones y las versiones de cuatro componentes, como 0.8.5.post1, 0.9.0.1 y 0.10.1.1. vLLM 0.14.1 es la primera versión fija. [S2] [S3] [S4] [S5]
Por qué es importante el contexto de implementación
Una dependencia vulnerable es una prueba importante de clasificación de parches, pero no es lo mismo que un servicio en vivo vulnerable. La exposición práctica depende de la versión del paquete implementado, de si ese tiempo de ejecución sirve a un modelo con capacidad de video, de si los usuarios que no son de confianza pueden proporcionar entrada de video y de si se puede acceder a la ruta de procesamiento relevante. [S1]
Cómo lo cubre FixVibe
Cubierto por FixVibe. Los escaneos de repositorio de GitHub pueden informar evidencia de dependencia de vLLM afectada de manifiestos de Python y archivos de bloqueo compatibles en un repositorio autorizado. El hallazgo identifica la fuente de dependencia, la versión o rango permitido, la versión fija, la confianza y una postura de evidencia de asesoramiento basada en versiones.
FixVibe no ejecuta vLLM, no inicia un servidor de modelos, no inspecciona las capacidades del modelo cargado, no envía ni recupera videos, no ejercita rutas de inferencia, realiza pruebas de fallas de decodificadores, no demuestra corrupción de memoria ni afirma la ejecución remota de código a partir de evidencia del repositorio. La verificación se limita intencionalmente al análisis de dependencia seguro.
Remediación
Actualice vLLM a 0.14.1 o posterior en la fuente de dependencia que controla la implementación. Regenere archivos de bloqueo activos y reconstruya cada servidor de inferencia, trabajador, cuaderno, imagen de CI, contenedor de servicio de modelos, entorno virtual, caché de rueda y caché de paquetes que lo instale. Verifique la versión en el artefacto en ejecución, no solo en el control de fuente. [S3] [S5]
Revise si los tiempos de ejecución implementados sirven modelos con capacidad de video o aceptan entrada de video. Hasta que se implemente la compilación fija, deshabilite o aísle el procesamiento de video que no sea de confianza y restrinja el acceso al servicio de modelos. Utilice comprobaciones de árboles de dependencia, comprobaciones de versiones en tiempo de ejecución, revisión de capacidad del modelo y pruebas de humo de inferencia benignas; no utilice medios elaborados ni intentos de explotación como verificación. El aviso ascendente y las correcciones vinculadas proporcionan el contexto de corrección autorizado. [S1] [S6] [S7] [S8]