Uma só mensagem, a correr como root
A equipa de investigação de segurança da JFrog divulgou a CVE-2026-105192 a 7 de outubro, classificando-a em 9,8 e crítica. Foi encontrada por Yuval Moravchick, da mesma equipa. À data do aviso não existe versão corrigida.
O LMCache é a camada de cache chave-valor que as instalações de vLLM usam para manter vivas as caches de atenção entre pedidos e entre máquinas. Em modo multiprocesso abre um socket ROUTER de ZeroMQ sem cifra CURVE, sem autenticação ZAP, sem palavra-passe e sem qualquer autenticação de mensagens. As mensagens chegam em msgpack. O código de extensão 1 está registado para um tipo chamado DeviceIPCWrapper, cujo método Deserialize chama o pickle.loads do Python.
Essa chamada acontece enquanto o servidor descodifica os argumentos de um pedido REGISTER_KV_CACHE — antes de correr qualquer lógica de tratamento. Logo, uma única mensagem não autenticada executa código com o utilizador do processo LMCache. As imagens de contentor oficiais correm esse processo como root.
Estar exposto depende de um único parâmetro
O 9,8 não é a história toda, e a JFrog di-lo. O transporte liga-se a localhost a menos que o operador defina um endereço encaminhável com --host, e a pontuação crítica aplica-se a essa configuração encaminhável. Nas palavras do aviso, “uma instalação padrão num único anfitrião que mantenha a ligação por omissão não é alcançável a partir de outras máquinas”.
O LMCache usado apenas dentro de um processo vLLM nem sequer abre a porta. A forma exposta é a instalação multi-nó — aquela a que se recorre quando uma máquina deixa de chegar, que é também a que mais provavelmente está a servir tráfego de produção.

Sem correção, as mitigações são suas
As versões 0.3.9 e posteriores estão afetadas. A JFrog pede ao projeto que substitua o serializador por trás do código de extensão 1 do msgpack por um formato seguro, que deixe de chamar pickle.loads sobre dados de pares não autenticados, que autentique o transporte com CURVE ou um HMAC por mensagem, e que recuse uma ligação encaminhável sem autenticação configurada.
Até existir uma versão corrigida, o conselho aos operadores é seco: não definir --host para um endereço encaminhável, manter a porta 5555 em localhost ou numa rede de cluster de confiança, e protegê-la com firewall. A JFrog acrescenta a ressalva que importa: quem conseguir ligar-se continua a poder correr código com o utilizador do LMCache.
A mesma classe de erro, duas vezes numa semana
Desserializar com pickle dados vindos da rede é um erro de Python com vinte anos de registo, e aparece agora na canalização do serviço de modelos. No Pwn2Own da Irlanda, na mesma semana, o LiteLLM caiu logo no primeiro dia com validação de entrada deficiente encadeada com injeção de código, por 40.000 dólares, e uma segunda equipa derrubou-o com mais quatro erros.
A parte propriamente de IA nisto não é a vulnerabilidade. É que uma camada de cache colocada entre um servidor de modelos e as suas GPU foi construída com um plano de controlo não autenticado, por se assumir que a instalação viveria numa rede de confiança.

O que verificar esta noite
Duas perguntas resolvem quase tudo: a porta 5555 é alcançável a partir de algo que não o anfitrião, e o contentor corre como root? Se a resposta a ambas for sim, o aviso descreve um caminho de um único pacote até uma shell numa máquina onde estão os seus pesos de modelo.
O que vale a pena observar é a versão corrigida. Até lá, isto é um buraco conhecido, pontuado e publicamente documentado, com um intervalo de correção, num componente que a maioria das equipas que corre vLLM em escala não escolheu tanto como herdou.