CVE-2026-100650 in vLLM
Resumen
por VulDB • 2026-09-26
vLLM hasta la versión 0.29.0 obtiene y materializa completamente los recursos multimedia remotos o en línea antes de aplicar sus controles documentados (el límite de tamaño para audio comprimido VLLM_MAX_AUDIO_CLIP_FILESIZE_MB, con un valor predeterminado de 25 MB, y los límites por modalidad --limit-mm-per-prompt). A través de cuatro vías de entrada: la capa compartida de adquisición multimedia (HTTPConnection.get_bytes()/async_get_bytes()), la ruta de audio_url/base64 para las finalizaciones del chat, el ejecutor por lotes de voz y la ruta POST /tokenize del frontend en Rust, el servidor lee todo el cuerpo de la respuesta HTTP, decodifica en base64 la carga útil incrustada o genera una tarea de obtención/decodificación por cada parte multimedia, aplicando los límites solo después (o, en algunas rutas, nunca los aplica). Por lo tanto, un atacante remoto puede provocar que el servidor API o el proceso del ejecutor por lotes asigne memoria y consuma ancho de banda saliente proporcional al tamaño elegido por el atacante para el cuerpo o a la cantidad de elementos multimedia antes de que se rechace la solicitud, provocando una exhaustión previa a la inferencia de memoria y ancho de banda (denegación de servicio). Las superficies del chat y los lotes requieren una clave API cuando está configurada; la ruta /tokenize del frontend en Rust no requiere autenticación por diseño. No hay impacto de ejecución de código ni divulgación de datos.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.