La entrada multimodal como superficie de ataque: la RCE del decodificador de vídeo de vLLM (CVE-2026-22778)
CVE-2026-22778 convierte una URL de vídeo maliciosa en ejecución remota de código en servidores vLLM, encadenando una fuga de información de PIL con un desbordamiento de montículo en el decodificador JPEG2000 de FFmpeg. Corregido en 0.14.1.
En resumen La mayor parte de lo que se escribe sobre seguridad de LLM trata sobre prompts. CVE-2026-22778 recuerda que el pipeline de decodificación de medios de un servidor de inferencia también es una superficie de ataque. Un vídeo malicioso enviado a un endpoint de vLLM que sirve un modelo de vídeo puede encadenar una fuga de dirección de memoria con un desbordamiento de montículo en un decodificador nativo incrustado para lograr ejecución remota de código, sin ninguna inyección de prompt. Afecta a vLLM
0.8.3–0.14.0; la corrección está en 0.14.1. vLLM se distribuye sin autenticación por defecto, lo que hace que los despliegues expuestos sean directamente alcanzables.
¿Qué es esto?
vLLM es uno de los motores más desplegados para servir grandes modelos de lenguaje, con un paquete de Python descargado más de tres millones de veces al mes. Cuando sirve un modelo multimodal, la entrada del usuario ya no es solo texto: las imágenes y los vídeos se envían a la API y se decodifican antes de llegar al modelo.
CVE-2026-22778 (aviso de GitHub GHSA-4r2x-xpjr-7cvv), analizada públicamente por OX Security en una publicación aparecida el 2 de febrero de 2026 y registrada desde entonces en la NVD y varias bases de datos de vulnerabilidades, es un fallo de ejecución remota de código en esa ruta de decodificación. Un atacante capaz de enviar una URL de vídeo manipulada a una instancia de vLLM que sirve un modelo de vídeo puede ejecutar comandos arbitrarios en el host. Los despliegues que no sirven un modelo de vídeo no se ven afectados.
Cómo funciona
El problema divulgado es un exploit encadenado: dos debilidades separadas, débiles por sí solas pero devastadoras juntas. Describimos el mecanismo a nivel conceptual; aquí no se reproduce ningún payload funcional.
El primer eslabón es una fuga de información. Cuando se envía una imagen no válida al endpoint multimodal, la biblioteca PIL lanza un error cuyo mensaje se devuelve al cliente. Ese mensaje incluye una dirección de memoria del montículo. Filtrar una sola dirección válida colapsa el espacio de búsqueda que el ASLR (Address Space Layout Randomisation) debe proteger; los defensores han descrito el efecto como reducir unos cuatro mil millones de posibilidades a un puñado.
El segundo eslabón es un desbordamiento de montículo en el decodificador JPEG2000. vLLM utiliza OpenCV para decodificar vídeos, y OpenCV incrusta FFmpeg 5.1.x. El decodificador JPEG2000 confía en los metadatos de definición de canales (cdef) de la imagen para reasignar canales de color sin revalidar los tamaños de búfer, de modo que datos destinados a un canal pueden escribirse en el búfer más pequeño de otro, desbordando hacia la memoria de montículo adyacente. Como el atacante controla tanto la geometría de la imagen como la asignación de canales, controla cuánta memoria se sobrescribe y qué objetos vecinos se ven afectados. Combinado con la dirección filtrada del paso anterior, ese control basta para sobrescribir un puntero de función y redirigir la ejecución a una rutina de libc como system().
El desencadenante es un uso normal de la API: una URL de vídeo pasada a una llamada de completado o invocación para un modelo de vídeo. Una instancia de vLLM instalada por defecto desde pip o Docker no tiene ninguna autenticación, por lo que un endpoint expuesto a Internet puede alcanzarse directamente.
Por qué importa
La lección va mucho más allá de esta única CVE. Los equipos razonan intensamente sobre inyección de prompts y jailbreaks, y luego reenvían imágenes y vídeos no confiables directamente a decodificadores nativos en C/C++ —código con un largo historial de fallos de seguridad de memoria— que se ejecutan en el mismo proceso que el modelo y sus credenciales. La parte de «IA» de la pila hereda todos los riesgos clásicos de corrupción de memoria de las bibliotecas de procesamiento de medios subyacentes.
El radio de impacto es amplio por la ubicación de los servidores de inferencia: cerca de las GPU, los pesos de los modelos, las redes internas y las claves de API. Una RCE aquí significa toma de control total del servidor, exfiltración de datos y movimiento lateral. Y el desbordamiento residía en una dependencia de terceros incrustada, de modo que una organización puede estar expuesta sin haber escrito ni revisado nunca la línea vulnerable. En el momento de la divulgación no había pruebas públicas de explotación activa, pero el rango afectado abarca muchas versiones.
Defensas
- Actualice a vLLM 0.14.1 o posterior. La corrección llegó a través de las pull requests #31987, #32319 y #32668: sanea los mensajes de error que filtran información y actualiza el decodificador vulnerable. Compruebe su versión con
pip show vllm. - Desactive la función de modelo de vídeo en producción hasta aplicar el parche si no puede actualizar de inmediato. Los despliegues que solo sirven texto o imágenes a través de las rutas corregidas no están expuestos a esta cadena concreta.
- Nunca exponga un endpoint de vLLM en bruto a redes no confiables. vLLM no tiene autenticación por defecto; colóquelo detrás de una pasarela autenticada, restrinja la entrada y trate cada objeto multimedia subido como entrada hostil.
- Aísle (sandbox) la capa de decodificación e inferencia. Ejecute el servicio en un contenedor mínimo con salida de red restringida y privilegios mínimos, segmentado de los almacenes de datos sensibles, para que un compromiso del decodificador no pueda pivotar hacia el resto del entorno.
- No devuelva al cliente errores en bruto de las bibliotecas. Filtrar el texto de la excepción —direcciones, marcos de pila, rutas— es una primitiva de fuga de información recurrente. Capture y reemplace los mensajes de error internos en la frontera de la API.
- Vigile sus dependencias nativas. Los decodificadores de imágenes y vídeos (OpenCV, FFmpeg, PIL) forman parte de su superficie de ataque LLM. Fíjelos y monitorícelos en su SBOM, y parchéelos con la misma urgencia que el propio framework del modelo.
Estado
| Elemento | Referencia | Fecha | Notas |
|---|---|---|---|
| Aviso CVE-2026-22778 | GitHub (GHSA-4r2x-xpjr-7cvv) | 2026 | Fuga de info + desbordamiento de montículo encadenados, RCE por vídeo |
| Análisis técnico público | OX Security | 2026-02-02 | Fuga de dirección de PIL + desbordamiento JPEG2000 de FFmpeg |
| Versiones afectadas | vLLM | 0.8.3 → 0.14.0 | Solo despliegues que sirven un modelo de vídeo |
| Versión corregida | vLLM 0.14.1 | — | Corrección PR #31987, #32319, #32668 |
El encuadre correcto no es «otra CVE de vLLM». Es que los endpoints multimodales extienden discretamente la superficie de ataque de un servicio LLM hasta código de medios nativo de hace décadas, y esa superficie merece el mismo aislamiento, la misma desconfianza ante las entradas y la misma higiene de dependencias que cualquier otro analizador no confiable.