O CVE-2025-62164 é uma vulnerabilidade de alta gravidade no vLLMum dos mecanismos de inferência LLM de código aberto mais amplamente implementados. O problema está dentro do API de conclusões e é acionado quando o servidor processa incorporação de prompt fornecida pelo usuário. Nas versões afetadas (0.10.2 até, mas não incluindo, 0.11.1), o vLLM desserializa os tensores usando torch.load() sem uma validação forte. Um tensor esparso criado pode passar despercebido e causar um gravação fora dos limites durante a densificaçãoque trava o trabalhador de forma confiável e pode ser escalado para execução remota de código sob as condições certas. O projeto enviou uma correção em vLLM 0.11.1. (NVD)

Duas coisas fazem com que este CVE pareça diferente dos bugs comuns de pilha de IA. Primeiro, é um falha no plano de dadosEm primeiro lugar, o problema não é uma interface de usuário do administrador ou uma configuração incorreta, mas um caminho de exploração que pode ser acessado por meio do mesmo endpoint de inferência que seus usuários acessam para obter conclusões. Em segundo lugar, ele está localizado na interseção exata de desserialização insegura e desvio de comportamento upstreamuma combinação que continua aparecendo à medida que a infraestrutura do LLM amadurece.

Onde o vLLM se situa na pilha e por que esse posicionamento aumenta o risco

O vLLM é efetivamente uma camada de inferência otimizada para a taxa de transferência. As equipes o implantam como uma API SaaS pública, por trás de um gateway corporativo ou como back-end de serviço para sistemas de agentes multilocatários. Em todos esses layouts, o vLLM está próximo da Internet e dos recursos de GPU. Isso soa como engenharia de desempenho, mas também significa Os chamadores de API de baixo privilégio podem acessar caminhos de código privilegiados. (wiz.io)

Portanto, o raio da explosão não é sutil. Um único endpoint que pode sofrer uma pane pode gerar inanição da GPU, acúmulo de filas, agitação do autoscaler e incidentes com vizinhos barulhentos. Se a exploração se estabilizar em RCE, a frota de inferência se tornará um ponto de apoio legítimo para a invasão da cadeia de suprimentos.

A vulnerabilidade em um parágrafo

O endpoint Completions nas versões vulneráveis do vLLM permite que os clientes passem incorporação imediata em vez de texto bruto. O vLLM reconstrói esses tensores por meio de torch.load() sem verificações suficientes de integridade, tipo ou estrutura. Desde que O PyTorch 2.8.0 desativa as verificações de integridade do tensor esparso por padrãoSe o tensor esparso for mal-intencionado, ele poderá contornar as proteções de limites internos e acionar um gravação de memória fora dos limites quando to_dense() é chamado de. O resultado imediato e repetível é DoS remoto (falha do trabalhador). Com layout e controle de memória favoráveis, a mesma primitiva poderia ser plausivelmente transformada em RCE no host. (NVD)

Anatomia da causa raiz: como a "passagem conveniente de incorporação" se transformou em corrupção de memória

Um coletor de desserialização em um endpoint público

torch.load() é poderoso por design. Seu objetivo é restaurar tensores e gráficos de objetos de fontes confiáveis (pontos de verificação, pipelines internos). No caso do vLLM, ele é usado em um campo que pode ser preenchido por um chamador de API. Isso muda o limite de confiança de "artefato de modelo interno" para "entrada de internet não confiável", que é historicamente onde a desserialização insegura explode. (NVD)

Embora esse problema se manifeste como corrupção de memória em vez de uma cadeia clássica de pickle-RCE, o erro subjacente é o mesmo: tratar uma estrutura binária complexa como se fosse apenas mais um parâmetro de solicitação.

A mudança de comportamento do PyTorch 2.8.0 foi a faísca

A consultoria vLLM e o NVD identificam o escalonamento em uma alteração no PyTorch: as verificações de integridade do tensor esparso agora estão desativadas por padrão. Anteriormente, era mais provável que os tensores esparsos malformados fossem rejeitados antes que o caminho do código atingisse a densificação. Com as verificações desativadas, a falta de pré-validação do vLLM tornou-se explorável de forma consistente. (NVD)

Esse é um modelo mental útil para a segurança da infraestrutura de IA: Os padrões upstream podem silenciosamente transformar "inseguro, mas inativo" em "inseguro e armável".

Verificação da realidade do impacto: DoS é garantido, RCE é um teto

Todos os registros públicos concordam que O DoS remoto é confiável. Uma única solicitação malformada pode matar um trabalhador; solicitações repetidas podem manter uma frota instável. (ZeroPath)

O RCE é descrito como potencial por um bom motivo. A corrupção da memória oferece um caminho, mas o armamento depende do comportamento do alocador, dos sinalizadores de proteção, dos limites do contêiner e do grau de controle que o invasor tem sobre a região corrompida. Há nenhuma listagem da CISA KEV e nenhuma cadeia de exploração amplamente confirmada em 25 de novembro de 2025, mas tratar a corrupção de memória do plano de dados como "somente DoS" seria um erro. (wiz.io)

Versões afetadas e status da correção

(NVD)

Quem deve entrar em pânico primeiro: Modelos de ameaças que importam

Se você quiser uma lente de priorização prática, pense em onde os embeddings podem entrar em seu sistema.

Os endpoints vLLM públicos são o caso óbvio de alto risco. Mesmo que os chamadores precisem de uma chave de API, o nível é baixo: um usuário normal com acesso básico pode ser suficiente para travar seus funcionários. (wiz.io)

As plataformas multilocatário de "LLM como serviço" são as próximas. O perigo é que as incorporações possam fluir em indiretamente - por meio de cadeias de ferramentas, plug-ins, estruturas de agentes ou serviços upstream que passam os embeddings como uma otimização. Quanto mais lugares você aceitar cargas úteis que não sejam de texto, mais complicado será o limite de confiança.

Por fim, não desconsidere as demonstrações comunitárias e as implementações educacionais. Elas geralmente não são autenticadas, são pouco monitoradas e ficam expostas muito tempo depois de o proprietário esquecer que elas existem.

Maneiras seguras de confirmar a exposição (sem sondagem arriscada)

A triagem mais rápida é baseada em versões.

python -c "import vllm; print(vllm.__version__)"
# afetado se 0.10.2 <= versão < 0.11.1

(NVD)

Operacionalmente, procure um padrão de falhas de segurança do trabalhador ou reinicializações abruptas vinculados a solicitações de conclusão incomumente grandes ou estruturalmente estranhas. Na prática, os picos de falhas aparecem primeiro; a exploração sofisticada (se chegar a acontecer) vem depois. (ZeroPath)

Uma verificação canária inofensiva - conclusões padrão, sem passagem de incorporação - é útil para a estabilidade da linha de base em torno da aplicação de patches:

importar solicitações, json, tempo

HOST = "https:///v1/completions"
headers = {"Authorization": "Bearer "}

payload = {
    "model": "your-model-name",
    "prompt": "health check",
    "max_tokens": 4
}

for i in range(5):
    r = requests.post(HOST, headers=headers, data=json.dumps(payload), timeout=10, verify=False)
    print(i, r.status_code, r.text[:160])
    time.sleep(1)

Faça um patch rápido e depois proteja o plano de dados

A verdadeira solução é simplesmente atualizar para vLLM 0.11.1 ou posterior. Todo o resto é um paliativo. (NVD)

Depois disso, trate as "entradas de inferência binária" como sumidouros de alto risco. Se o seu produto realmente precisar de passagem de incorporação, bloqueie-o com uma validação de esquema rigorosa: imponha tipos de dados de tensor esperados, formas, tamanhos máximos e proíba formatos esparsos, a menos que você os suporte explicitamente. Até mesmo uma lista de permissões simples bloqueia a classe específica de estruturas malformadas nas quais esse CVE se baseia. (wiz.io)

No lado da infraestrutura, bloqueie o raio de explosão. Os funcionários do vLLM devem ser executados com privilégios mínimos, sistemas de arquivos somente leitura sempre que possível, sem montagens de host confidenciais e perfis seccomp/AppArmor de contêiner. Se alguém encadear a corrupção de memória na execução do código, você quer que ela fique presa em uma caixa que não possa alcançar segredos ou caminhos laterais.

Por que o CVE-2025-62164 é importante para a segurança de IA como disciplina

Esse incidente é um exemplo claro de como a segurança de IA está se afastando dos manuais clássicos de aplicativos da Web.

A nova fronteira é planos de dados de serviço de modeloOs dados de APIs são apresentados em uma lista de dados: tensores, embeddings, blobs multimodais e artefatos serializados que passam pelas APIs porque são rápidos e convenientes. Eles também são estruturalmente ricos e frágeis - perfeitos para bugs de corrupção se você desserializar sem paranoia.

Também é um lembrete de que a superfície de risco de uma pilha de LLM é composicionalO vLLM não "inventou" a insegurança do tensor esparso; um padrão do PyTorch foi alterado, e uma camada de validação ausente a jusante transformou essa alteração em um CVE. A engenharia de inferência agora precisa do mesmo nível de escrutínio de dependência que as equipes do kernel têm como certo.

Validação controlada quando os PoCs são confusos ou tardios

Os CVEs de infraestruturas de IA geralmente chegam antes de PoCs públicas estáveis ou com PoCs que são muito arriscadas para serem apontadas para clusters de serviço de produção. A abordagem defensável é industrializar um ciclo mais seguro: informações confiáveis → hipótese → validação somente em laboratório → evidência auditável.

Em fluxos de trabalho agênticos no estilo Penligent, é possível fazer com que os agentes ingiram o registro de NVD e de consultoria vLLM, derivem as condições exatas de exposição (versões, caminho de incorporação, suposições do PyTorch) e gerem um plano de validação de risco mínimo que você executa somente em uma réplica isolada. Isso lhe dá uma prova real - impressões digitais da versão, assinaturas de falhas, deltas pré/pós-patch - sem apostar em suas GPUs de produção. (NVD)

Tão importante quanto isso é o fato de que os relatórios com base em evidências facilitam a explicação da urgência para a liderança de operações. "Fizemos a correção porque um blog disse isso" não sobrevive à análise de incidentes. "Fizemos a correção porque a réplica do nosso laboratório pode falhar por meio do caminho vulnerável dos embeddings, e aqui está a linha do tempo e o diff após a atualização para a versão 0.11.1". CVE-2025-62164 PoC: bug no plano de dados de conclusões do vLLM que transforma os embeddings em uma superfície de ataque