Kernelclint

**Nome do Software Vulnerável e Versões Afetadas** vLLM versões anteriores a 0.30.0 **Description** No vLLM, continuações de ferramentas Harmony enviadas através do endpoint "POST /v1/responses" reconstroem a entrada do motor do próximo turno sem preservar o valor `cache salt`. Isso faz com que o prefixo de continuação seja armazenado no namespace de cache global não salgado, mesmo quando o chamador habilitou o salting para isolamento de locatários. Em implantações onde o cache de prefixo está habilitado (configuração padrão), um locatário autenticado que consiga reconstruir o histórico pós-ferramenta de baixa entropia de uma vítima pode enviar a mesma continuação e usar a contagem de `cached tokens per turn` para determinar se o prefixo foi processado anteriormente. Isso efetivamente cria um oráculo de associação de prompt que anula o isolamento pretendido do cache de prefixo salgado. **Recommendations** Atualize o vLLM para a versão 0.30.0 ou posterior.

**Nome do Software Vulnerável e Versões Afetadas** vLLM versões anteriores a 0.28.0 **Description** Existe uma dessincronização de espelhamento de cache no cache LRU multimodal padrão quando o `mm processor cache type` está definido como `lru`. O sistema espelha o estado entre um cache de envio do frontend (`MultiModalProcessorSenderCache`) e um cache de recebimento do motor (`MultiModalReceiverCache`). Se uma solicitação for rejeitada após o frontend ter renderizado e gerado o hash da entrada multimodal, mas antes que o receptor do motor receba a carga útil (por exemplo, devido a uma rejeição de `max model len`), o cache do frontend registra incorretamente o item como armazenado, enquanto o cache do receptor permanece vazio. Uma solicitação posterior usando a mesma variável `mm hash` disparará um acerto de cache no frontend, fazendo com que ele não envie a carga útil. Isso leva o cache do receptor a disparar uma falha de asserção na função `get and update item()` com a mensagem "Expected a cached item", resultando em uma falha de disponibilidade do serviço compartilhado. **Recommendations** Atualize o vLLM para a versão 0.28.0 ou posterior. Como mitigação temporária, evite usar o tipo de cache `lru` para processamento multimodal, alterando a configuração `mm processor cache type`.

**Nome do Software Vulnerável e Versões Afetadas** vLLM versões anteriores a 0.30.0 **Description** No caminho de escala desagregada (disaggregated scale-out), o endpoint `/inference/v1/generate` não valida nem vincula o estado multimodal fornecido pelo chamador ao contrato do renderizador do modelo ativo. Isso permite que um invasor autenticado envie dados forjados através do objeto `features`, afetando especificamente os campos `kwargs data`, `mm hashes` e `mm placeholders`. Esta falha pode levar a vários resultados críticos: - Negação de Serviço (DoS): A forja de geometria de grade, tipos de campo ou o fornecimento de comprimentos de placeholder não positivos podem causar a falha fatal do processo EngineCore compartilhado, resultando na interrupção total do serviço para todos os locatários. - Envenenamento e Divulgação de Cache: Como os `mm hashes` (usados como chaves de cache) não estão vinculados ao payload real, um invasor que conheça ou consiga induzir o hash de conteúdo de uma vítima pode envenenar ou recuperar o estado do cache do codificador entre requisições. - Perda de Integridade: A exclusão de máscaras de placeholder esparsas durante a reprodução de renderização para geração pode alterar a semântica de transporte para modelos que dependem dessas máscaras. **Recommendations** Atualize o vLLM para a versão 0.30.0 ou posterior. Como mitigação temporária, restrinja o acesso ao endpoint `/inference/v1/generate` apenas a serviços internos confiáveis para evitar que usuários autenticados não autorizados enviem payloads multimodais forjados.

**Nome do Software Vulnerável e Versões Afetadas** vLLM versões anteriores a 0.30.0 **Description** Em implantações que utilizam a pontuação de interação tardia flash (flash late-interaction scoring), o mecanismo deriva as chaves de cache do worker para incorporações de consulta (query embeddings) a partir do cabeçalho `X-Request-Id`, que é controlado pelo chamador. Uma requisição concorrente que reutilize o identificador de uma vítima pode sobrescrever a incorporação de consulta em cache, fazendo com que os documentos da vítima sejam pontuados em relação à consulta do invasor. Além disso, contadores de uso compartilhados podem causar um erro de cache-miss de interação tardia. Este problema afeta os endpoints `/score` e `/rerank`. **Recommendations** Atualize o vLLM para a versão 0.30.0 ou posterior. Como mitigação temporária, restrinja ou sanitize o cabeçalho `X-Request-Id` para evitar que os usuários forneçam valores arbitrários.

**Nome do Software Vulnerável e Versões Afetadas** vLLM versões anteriores a 0.30.0 **Description** o vLLM é um mecanismo de inferência e serviço para grandes modelos de linguagem. Modelos de requisição compatíveis com OpenAI aceitam um valor `cache salt` sem impor as restrições de caracteres e comprimento exigidas pelo consumidor `IPCCacheServerKey` no LMCache-MP. Em implantações que utilizam o conector LMCache-MP, um salt que contenha caracteres proibidos (como `@`, `/`, `` ou NUL) ou que exceda 128 caracteres pode disparar um `ValueError` não capturado durante a busca de cache do agendador. Como a função `Scheduler.schedule()` não envolve essa chamada em um manipulador de exceção com escopo de requisição, o erro se propaga para o manipulador de nível superior do `EngineCore`, que trata qualquer exceção não capturada como fatal e encerra todo o processo do mecanismo. Isso resulta em uma negação de serviço para todos os usuários simultâneos. O problema é desencadeado através da variável `cache salt` em modelos de requisição, incluindo Completions, Chat Completions e Responses. **Recommendations** Atualize o vLLM para a versão 0.30.0 ou posterior. Como mitigação temporária, evite usar o parâmetro `cache salt` em requisições ou garanta que ele não contenha os caracteres `@`, `/`, `` ou NUL e não exceda 128 caracteres.

**Nome do Software Vulnerável e Versões Afetadas** vLLM versões anteriores a 0.30.0 **Description** Falhas em requisições de saída estruturada podem ignorar a validação de escopo da requisição e atingir o caminho de erro fatal do `EngineCore`, permitindo que requisições comuns de geração restrita encerrem o motor compartilhado e causem a negação de serviço para todos os locatários simultâneos e subsequentes. Isso ocorre devido à ausência de um limite de exceção por requisição no processamento de gramática e tokens de saída estruturada. Os detalhes técnicos incluem três caminhos de falha distintos: 1. Uma incompatibilidade de backend no `StructuredOutputManager` pode fazer com que uma exceção de compilação de gramática seja relançada durante a promoção do escalonador, derrubando o motor. Isso afeta o backend padrão `auto`. 2. No modo de decodificação especulativa `ngram gpu`, valores de preenchimento `-1` podem ser passados para a função `validate tokens()` no backend `guidance`. O correspondente nativo não consegue converter esse valor negativo para um tipo de token sem sinal, disparando um `OverflowError` fatal. 3. O frontend em Rust pode aceitar strings vazias em `structured outputs.json` ou `structured outputs.grammar` que o frontend em Python rejeitaria, permitindo que esses valores vazios cheguem ao motor e marquem o `EngineCore` como morto. **Recommendations** Atualize o vLLM para a versão 0.30.0. Como mitigação temporária, evite usar o backend `guidance` em combinação com a decodificação especulativa `ngram gpu`. Restrinja o uso do frontend em Rust ou garanta que os parâmetros `structured outputs.json` e `structured outputs.grammar` não sejam enviados como strings vazias.

**Nome do Software Vulnerável e Versões Afetadas** vLLM versões anteriores a 0.29.1 **Description** O servidor busca e materializa completamente mídias remotas ou inline antes de aplicar os controles de mídia, como o limite de tamanho `VLLM MAX AUDIO CLIP FILESIZE MB` e os limites de itens `--limit-mm-per-prompt`. Isso ocorre em quatro caminhos de entrada: a camada de aquisição de mídia compartilhada `HTTPConnection.get bytes()`/`async get bytes()`, o caminho `audio url`/`base64` de conclusões de chat, o executor de fala em lote (batch speech runner) e a rota `POST /tokenize` do frontend Rust. Como o servidor lê todo o corpo da resposta HTTP ou decodifica o payload base64 antes de aplicar os limites, um invasor remoto pode causar a alocação de memória e o consumo de largura de banda de saída proporcionais ao tamanho do corpo ou à contagem de itens de mídia escolhidos. Isso leva à exaustão de memória e largura de banda pré-inferência, resultando em negação de serviço. Embora as superfícies de chat e lote possam exigir uma chave de API, a rota `POST /tokenize` não requer autenticação. **Recommendations** Atualize para uma versão posterior a 0.29.0. Restrinja o acesso à rota `POST /tokenize` para minimizar o risco de exploração não autenticada.

**Nome do Software Vulnerável e Versões Afetadas** vLLM versões 0.22.1 through 0.27.9 **Description** Um problema de integridade da cadeia de suprimentos e reprodutibilidade ocorre quando o pin de revisão do modelo fornecido via `--revision` ou `--code-revision` não é propagado para carregamentos específicos de artefatos do Hugging Face para as arquiteturas FunAudioChat e Tarsier2. Especificamente, isso afeta os carregamentos de `WhisperFeatureExtractor` e `speech tokenizer` `PreTrainedTokenizerFast` em `vllm/model executor/models/funaudiochat.py`, bem como a função `Qwen2VLConfig.from pretrained()` usada por `TarsierProcessingInfo` em `vllm/model executor/models/qwen2 vl.py`. Consequentemente, implantações fixadas em uma revisão específica podem carregar artefatos de processador, tokenizador e configuração da revisão padrão do repositório, permitindo que alterações posteriores no branch padrão upstream alterem o pré-processamento de áudio, o comportamento do tokenizador de fala ou a configuração do Tarsier2 sem o conhecimento do operador. **Recommendations** Atualize o vLLM para a versão 0.28.0.