Las rutas de audio de vLLM cargan toda la subida antes de comprobar su tamaño

En resumen La seguridad de los LLM suele hablar de prompts. Esto va de fontanería. Una vulnerabilidad divulgada el 6 de julio de 2026 en los endpoints de audio de vLLM muestra que el servidor lee todo el archivo de audio en memoria antes de comprobar el límite de tamaño configurado — así, quien pueda alcanzar esas rutas puede enviar una subida sobredimensionada y forzar al proceso a asignar memoria proporcional al archivo, generando presión de memoria o matando el proceso. Afecta a las versiones 0.22.0–0.23.x; la corrección está en la 0.24.0. Este es un análisis de clase de fallo, no un exploit.

¿Qué es esto?

vLLM es uno de los motores más desplegados para servir grandes modelos de lenguaje. Cuando sirve un modelo de voz, expone rutas de audio compatibles con OpenAI — /v1/audio/transcriptions y /v1/audio/translations — que aceptan un archivo de audio enviado como petición multipart.

El fallo divulgado, publicado en el ecosistema CVE el 6 de julio de 2026 y documentado en el aviso de seguridad de GitHub de vLLM (GHSA-v82g-2437-67m2), es un error de orden en el tratamiento de esas subidas. vLLM ofrece un límite documentado para las subidas de audio — VLLM_MAX_AUDIO_CLIP_FILESIZE_MB, con 25 MB por defecto — pero esa comprobación se ejecuta más tarde, en el paso de preprocesamiento speech-to-text, después de que el archivo ya se ha cargado en memoria. Tiene una puntuación CVSS de 6.5 (media), con impacto limitado a la disponibilidad. No hay ejecución de código ni fuga de datos: el beneficio para el atacante es una denegación de servicio.

Cómo funciona

El mecanismo es un caso de manual de consumo de recursos no controlado (CWE-400 / CWE-770), y no hay nada exótico que reproducir — lo importante es la secuencia, no un payload.

Ciclo de vida de la petición en las rutas de audio (versiones vulnerables)
--------------------------------------------------------------------------
1. El cliente envía una subida de audio multipart a /v1/audio/transcriptions
2. El handler llama a request.file.read()  --> TODO el archivo se carga en RAM
3. Se ejecuta el preprocesamiento speech-to-text
4. Solo ahora: comparación con VLLM_MAX_AUDIO_CLIP_FILESIZE_MB
5. La petición sobredimensionada se rechaza al fin -- pero la memoria ya se gastó

Como todo el cuerpo se carga en el paso 2, la memoria que asigna vLLM depende del tamaño de subida elegido por el atacante, y no de la política de 25 MB que el operador cree que le protege. Una sola subida multipart sobredimensionada — o unas cuantas en paralelo — infla la memoria residente antes de que la petición sea descartada. Según los límites de recursos del despliegue, esto se traduce en latencia degradada para peticiones legítimas, presión de memoria crítica o la terminación directa del proceso. El aviso señala que estas rutas requieren cierto nivel de acceso, y que el fallo es alcanzable de forma remota por la red con baja complejidad.

Por qué importa

Los servidores de inferencia se tratan cada vez más como servicios web corrientes, pero soportan un coste por petición inusualmente alto: GPU, modelos residentes grandes, pipelines de preprocesamiento de medios. Eso los convierte en un blanco fácil para los ataques de agotamiento de recursos, cuyo objetivo no es robar sino tumbar un servicio de forma barata. Un límite de tamaño documentado pero aplicado después de la asignación costosa es un fallo común y fácil de pasar por alto — la protección existe, solo se ejecuta un paso demasiado tarde.

La lección más amplia: una entrada no confiable en una pila LLM debe acotarse antes de materializarse, la misma disciplina que necesita cualquier endpoint de subida de archivos. El marco de «IA» no cambia lo fundamental: una ruta de audio es una ruta de subida de archivos, y las rutas de subida que leen primero y validan después conducen a la denegación de servicio por agotamiento de memoria.

Defensas

1. Actualice a vLLM 0.24.0 o posterior. La corrección (pull request #45510) mueve la comprobación para que el límite de tamaño se aplique antes de cargar por completo la subida. Compruebe su versión con pip show vllm.
2. Imponga un límite de tamaño de cuerpo de petición en el borde. Coloque una pasarela o proxy inverso autenticado delante de vLLM y limite ahí el tamaño de las subidas (por ejemplo client_max_body_size en nginx), para que las peticiones sobredimensionadas se rechacen antes de llegar al proceso de inferencia. Esto defiende toda la clase, no solo esta ruta.
3. No exponga endpoints vLLM en crudo a llamantes no confiables. Por defecto, vLLM tiene autenticación débil o nula; restrinja el acceso entrante y exija autenticación en las rutas de audio.
4. Acote el proceso, no solo la política. Ejecute el servicio bajo límites de memoria de contenedor/cgroup con reinicio automático, para que un pico de memoria se degrade y recupere en lugar de tumbar el host. Añada rate limiting y cuotas por cliente en los endpoints de subida.
5. Valide el tamaño antes de la asignación, en todas partes. Trate el «leer todo y luego comprobar» como un anti-patrón en sus propias herramientas — haga streaming y rechace pronto en cualquier endpoint que acepte subidas no confiables.

Estado

Elemento	Referencia	Fecha	Notas
Aviso del fabricante	GitHub (GHSA-v82g-2437-67m2) — CVE-2026-55646	2026-07-06	Las rutas de audio cargan toda la subida antes de la comprobación de tamaño
Clase de fallo	CWE-400 / CWE-770	—	Consumo de recursos no controlado / sin límite de asignación
Severidad	CVSS 3.1 base 6.5 (media)	—	Red, baja complejidad; impacto solo en disponibilidad
Versiones afectadas	vLLM	0.22.0 → 0.23.x	Despliegues que sirven modelos speech-to-text
Versión corregida	vLLM 0.24.0	2026	Límite de tamaño aplicado antes de la carga (PR #45510)

El encuadre honesto no es «otra CVE de vLLM». Es que un servidor de inferencia es un servicio web con peticiones costosas, y la regla más antigua de las subidas no confiables sigue vigente: acote la entrada antes de gastar memoria en ella.