O que aconteceu: CVE-2026-100654 no vLLM

O vLLM é um servidor de inferência usado para disponibilizar modelos de linguagem por meio de APIs compatíveis com o padrão da OpenAI. A CVE-2026-100654 afeta versões anteriores à 0.29.0 e está relacionada ao tratamento do parâmetro stop_token_ids nos endpoints /v1/completions e /v1/chat/completions. O registro público informa que o servidor verifica se os valores são inteiros, mas não confirma se cada identificador pertence ao vocabulário ou ao intervalo de logits do modelo.

Essa diferença entre validar o tipo e validar o significado do valor é importante. Uma API pode receber um número inteiro perfeitamente bem formado e ainda assim não conseguir processá-lo com segurança. O risco principal documentado é de disponibilidade e estabilidade do serviço. A exposição depende de a instalação aceitar requisições controladas por usuários externos ou por clientes com autorização insuficiente.

Como funciona

Durante uma geração, o servidor usa tokens para representar texto e controlar quando a resposta deve parar. O parâmetro stop_token_ids informa identificadores que podem encerrar a geração. Esses identificadores precisam ser compatíveis com o vocabulário do modelo carregado e com as estruturas usadas pelo runtime.

Na versão afetada, a validação descrita no registro público confirma apenas que os itens recebidos são inteiros. Um cliente pode enviar valores que não existem no vocabulário ou estão fora do intervalo esperado. Quando a requisição passa por componentes de amostragem e geração, o valor inválido pode provocar comportamento inesperado, erro do worker, encerramento da requisição ou consumo anormal de recursos. O mecanismo exato deve ser confirmado no código e nos avisos do projeto para cada versão instalada.

O cenário pode aparecer tanto em requisições de conclusão quanto em conversas, porque os dois endpoints citados compartilham o parâmetro vulnerável. A exploração não exige necessariamente acesso ao sistema operacional. Basta alcançar a API com permissão para enviar os campos aceitos.

Quem foi afetado

São relevantes as implantações que executam vLLM antes da versão 0.29.0 e expõem os endpoints compatíveis com a API da OpenAI. Ambientes internos também entram no escopo se vários usuários, aplicações ou serviços puderem controlar diretamente os parâmetros de inferência.

Uma instalação atrás de um gateway pode reduzir a exposição, mas não deve ser considerada protegida automaticamente. Se o gateway repassa campos desconhecidos, não aplica autenticação forte ou permite que um cliente use valores arbitrários, o worker continua recebendo a entrada de risco. A avaliação deve considerar a versão efetiva em execução, o modelo, o adaptador de API, os plugins e a topologia de rede.

Serviços multiusuário, plataformas de agentes, aplicações de atendimento e ambientes de pesquisa compartilhados merecem prioridade. O impacto pode incluir respostas interrompidas, reinícios de processos, filas maiores e indisponibilidade para clientes legítimos.

Como identificar: detecção

Comece pelo inventário. Registre a versão do pacote vLLM, a imagem do container, o commit quando aplicável, o modelo carregado e os comandos usados na inicialização. Não confie somente no arquivo de dependências, pois a imagem em produção pode conter outra versão.

Nos logs do gateway e do servidor, procure requisições que contenham stop_token_ids com valores muito altos, listas excessivamente longas, valores repetidos ou padrões que não correspondam ao vocabulário do modelo. Correlacione esses eventos com erros de amostragem, exceções de índice, reinícios de worker, aumento de latência, crescimento de memória e encerramento inesperado de conexões.

Registre o identificador da requisição, a identidade autenticada e a origem, mas evite armazenar prompts e dados pessoais sem necessidade. Métricas de CPU, memória, GPU, fila e taxa de erro ajudam a separar uma entrada inválida isolada de uma sequência automatizada. Se houver suspeita de abuso, preserve os registros antes de alterar a configuração.

Como se proteger: mitigação

A medida prioritária é atualizar para uma versão que contenha a correção, seguindo as notas oficiais do vLLM e validando a compatibilidade com o modelo. Faça o processo em homologação, execute testes de regressão e confirme que todos os workers receberam a nova imagem. Uma atualização parcial deixa nós vulneráveis atrás do balanceador.

No gateway, aceite somente os campos necessários e valide stop_token_ids com base no tokenizer e no modelo permitido. Se a aplicação não precisa desse parâmetro, remova-o ou rejeite-o. Quando ele for necessário, imponha limite de quantidade, valide o intervalo de cada identificador e retorne erro claro para entradas inválidas antes de encaminhar a requisição.

Use autenticação, autorização por aplicação, rate limit, limite de tamanho de corpo, timeout e circuit breaker. Separe o endpoint de inferência da rede pública quando não houver necessidade de acesso externo. Limites de memória e reinício controlado reduzem o raio de impacto, mas não substituem a atualização. Mantenha uma imagem anterior somente como rollback planejado e monitorado.

Comparação com casos e alternativas anteriores

Falhas de validação de entrada aparecem em servidores de modelos, parsers, bibliotecas de tokenização e gateways. Em todos esses casos, o dado recebido pode estar correto no nível sintático e errado no nível semântico. A diferença é importante para equipes que aplicam apenas validações genéricas, como tipo numérico, tamanho máximo ou presença do campo.

Uma alternativa é centralizar a validação em um gateway independente. Isso reduz a quantidade de clientes que fala diretamente com o worker, mas cria a obrigação de manter a regra sincronizada com cada modelo. Outra alternativa é deixar o próprio servidor rejeitar o valor, que é necessária como última barreira. O desenho mais seguro combina as duas camadas sem presumir que uma delas seja suficiente.

Desabilitar temporariamente o parâmetro pode ser uma contenção válida quando a atualização precisa de testes. Porém, a decisão deve considerar as funcionalidades que dependem de paradas controladas e deve ser documentada para não virar uma mudança permanente sem revisão.

Análise técnica

O registro consultado identifica a CVE-2026-100654 e informa que versões do vLLM anteriores à 0.29.0 aceitam stop_token_ids controlados pelo usuário nos endpoints de completion e chat completion. A validação descrita confirma que os valores são inteiros, mas não que estejam dentro do vocabulário ou do intervalo de logits do modelo. O CVSS informado pelo coletor é 6.5.

O CVSS é uma medida de severidade, não uma garantia de que toda instalação terá o mesmo impacto. O resultado depende da exposição, das permissões, do modelo e do comportamento do runtime. Consulte o registro da CVE e a documentação oficial do vLLM. Testes de confirmação devem usar ambiente autorizado, modelo de teste, dados sintéticos e limites de recurso.

Impacto e consequências

O efeito operacional pode começar com falhas intermitentes em requisições e evoluir para perda de capacidade. Workers que encerram ou entram em estado de erro transferem carga para outras instâncias. Em um cluster perto do limite, essa redistribuição pode causar uma degradação em cascata.

Também existe impacto de observabilidade. Se os logs registram apenas erro genérico, a equipe pode interpretar o problema como instabilidade do modelo ou falha de GPU. Correlacionar parâmetros de entrada, cliente, versão e tempo do evento reduz o tempo de diagnóstico. Em serviços críticos, documente o plano de comunicação, a ordem de isolamento e os critérios para retorno ao tráfego.

Uma resposta lenta aumenta custos de computação, gera reprocessamento e pode afetar acordos de nível de serviço. Por isso, a correção deve ser tratada como atividade de segurança e confiabilidade, não apenas como atualização de dependência.

Dicas práticas e boas práticas

Use este checklist: confirme a versão real em cada worker; liste os modelos e tokenizers usados; identifique quem alcança os endpoints; verifique se o gateway repassa campos arbitrários; aplique validação semântica; limite tamanho e frequência; habilite métricas de erro e memória; teste a atualização; e documente rollback.

Inclua entradas inválidas nos testes automatizados. Cubra números negativos, valores fora do vocabulário, listas vazias, listas grandes, duplicatas e combinações com diferentes limites de geração. O objetivo é confirmar que a API rejeita o valor sem encerrar o worker e sem reter recursos.

Fixe versões de imagem, faça varredura das dependências, assine artefatos quando possível e mantenha uma lista de ativos afetados. Após a mudança, observe o sistema por tempo suficiente para capturar filas, reinícios e aumento progressivo de memória.

Conclusão: o que fazer agora

Se você executa vLLM antes da versão 0.29.0, confirme imediatamente se os endpoints vulneráveis estão acessíveis e quais clientes controlam stop_token_ids. Restrinja o acesso, filtre o parâmetro quando possível e priorize a atualização para uma versão corrigida indicada pelo projeto.

Depois da atualização, valide todos os workers e modelos, revise o gateway e mantenha alertas para erros de geração, reinícios e crescimento anormal de recursos. A lição mais ampla é que APIs de IA precisam validar o significado dos dados, não apenas o tipo. Essa prática reduz o risco de futuras falhas que usem outros parâmetros de controle.