O que diz o comunicado
O projeto vLLM divulgou CVE-2026-22778 / GHSA-4r2x-xpjr-7cvv como uma cadeia crítica de vulnerabilidade de processamento de vídeo. O comunicado revisado diz que uma implantação afetada pode atingir a execução remota de código quando serve um modelo com capacidade de vídeo e processa entrada de vídeo controlada pelo invasor. As implantações que não atendem a um modelo de vídeo não são afetadas por este comunicado. [S1] [S2]
Versões afetadas
As versões PyPI afetadas começam em vLLM 0.8.3 e param antes de 0.14.1. PyPA e OSV enumeram os lançamentos publicados afetados, incluindo lançamentos posteriores e de quatro componentes, como 0.8.5.post1, 0.9.0.1 e 0.10.1.1. vLLM 0.14.1 é a primeira versão fixa. [S2] [S3] [S4] [S5]
Por que o contexto de implantação é importante
Uma dependência vulnerável é uma importante evidência de triagem de patches, mas não é o mesmo que um serviço ativo vulnerável. A exposição prática depende da versão do pacote implantado, se esse tempo de execução atende a um modelo com capacidade de vídeo, se usuários não confiáveis podem fornecer entrada de vídeo e se o caminho de processamento relevante está acessível. [S1]
Como FixVibe cobre isso
Coberto por FixVibe. As varreduras de repositório GitHub podem relatar evidências de dependência de vLLM afetadas de manifestos Python suportados e arquivos de bloqueio em um repositório autorizado. A descoberta identifica a origem da dependência, a versão ou o intervalo permitido, a versão fixa, a confiança e uma postura de evidência consultiva baseada em versão.
FixVibe não executa vLLM, inicia um servidor de modelo, inspeciona recursos de modelo carregado, envia ou busca vídeo, exerce rotas de inferência, decodificadores de teste de colisão, prova corrupção de memória ou reivindica execução remota de código a partir de evidências de repositório. A verificação é intencionalmente limitada à análise de dependência segura.
Correção
Atualize o vLLM para 0.14.1 ou mais recente na fonte de dependência que controla a implantação. Gere novamente arquivos de bloqueio ativos e reconstrua cada servidor de inferência, trabalhador, notebook, imagem de CI, contêiner de serviço de modelo, ambiente virtual, cache de roda e cache de pacote que o instala. Verifique a versão no artefato em execução, não apenas no controle de origem. [S3] [S5]
Revise se os tempos de execução implantados atendem modelos compatíveis com vídeo ou aceitam entrada de vídeo. Até que a compilação fixa seja implantada, desabilite ou isole o processamento de vídeo não confiável e restrinja o acesso ao serviço de modelo. Use verificações de árvore de dependência, verificações de versão de tempo de execução, revisão de capacidade de modelo e testes de fumaça de inferência benignos; não use mídias criadas ou tentativas de exploração como verificação. O aconselhamento upstream e as correções vinculadas fornecem o contexto de correção oficial. [S1] [S6] [S7] [S8]