CVE-2026-100650 in vLLM
Sumário
de VulDB • 26/09/2026
O vLLM até a versão 0.29.0 busca e materializa completamente mídias remotas ou inline antes de aplicar seus controles documentados (como o limite de tamanho para áudio compactado VLLM_MAX_AUDIO_CLIP_FILESIZE_MB, com padrão de 25 MB, e os limites por modalidade --limit-mm-per-prompt). Em quatro caminhos de entrada — a camada compartilhada de aquisição de mídia (HTTPConnection.get_bytes()/async_get_bytes()), o caminho audio_url/base64 para conclusões de chat, o executor em lote de fala e a rota POST /tokenize do frontend Rust — o servidor lê todo o corpo da resposta HTTP, decodifica em base64 a carga útil inline ou cria uma tarefa de busca/decodificação por parte da mídia, aplicando os limites apenas depois (ou não os aplica em alguns caminhos). Um atacante remoto pode fazer com que o servidor API ou o processo do executor em lote aloque memória e consuma largura de banda proporcional ao tamanho escolhido pelo atacante ou à quantidade de itens de mídia antes que a solicitação seja rejeitada, resultando em esgotamento pré-inferência de memória e largura de banda (negação de serviço). As superfícies de chat e lote exigem uma chave API quando configurada; já a rota /tokenize do frontend Rust é não autenticada por design. Não há impacto de execução de código ou divulgação de dados.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.