O que aconteceu: Yuval Moravchick, da equipe de pesquisa da JFrog, encontrou no LMCache uma falha de desserialização que vira execução remota de código sem credencial. No modo multiprocesso, o LMCache sobe um soquete ZeroMQ do tipo ROUTER, por padrão na porta 5555, para que processos de trabalho compartilhem blocos de cache de KV. Esse soquete não tem CURVE, não tem ZAP, não tem senha e não valida mensagem. As mensagens são msgpack, e o código de extensão 1 está registrado para o objeto DeviceIPCWrapper, cujo método Deserialize chama pickle.loads no corpo da extensão. Isso acontece durante a decodificação dos argumentos de um REGISTER_KV_CACHE, antes de qualquer handler olhar a requisição. Uma mensagem só, de um soquete DEALER qualquer, executa comando no usuário do processo. As imagens oficiais rodam esse processo como root. O padrão é escutar em 127.0.0.1, e a nota 9,8 vale para quem define um endereço roteável com --host, que é o que a documentação de múltiplos nós manda fazer.
A cadeia de exploração aqui é curta demais para dar conforto. Alcançar a porta é a única pré-condição. Não há login, não há token, não há etapa de negociação. O que acontece em seguida é a biblioteca de serialização do Python executando o que recebeu.
O exploit cabe em três passos
É assim que a prova de conceito da JFrog funciona:
- Subir o modo multiprocesso em um endereço roteável, como o manual de múltiplos nós recomenda.
- Mandar um quadro
REGISTER_KV_CACHEem que um dos argumentos é uma extensão msgpack carregando um objeto pickle. - Esperar a decodificação. O pickle executa ali, e o servidor só devolve um erro de tipo depois que o comando já rodou.
Em imagem oficial, esse comando roda como root dentro do contêiner.
Quem está no alcance e quem não está
- LMCache usado dentro do próprio processo do vLLM não abre essa porta. Esse caso está fora.
- Instalação de um nó só, com o bind padrão em
127.0.0.1, não é alcançável de outra máquina. - O risco se concentra em implantação de múltiplos nós e em Kubernetes, onde o LMCache sobe como servidor separado e as réplicas do vLLM se conectam a ele por endereço roteável.
- Em cluster de GPU, quem alcança a porta normalmente é outro pod, outro inquilino ou um job de pipeline, não a internet aberta. É movimentação lateral com execução imediata.
O tamanho do alvo não é pequeno. O projeto nasceu de pesquisa na Universidade de Chicago, acumula mais de 11 mil estrelas no repositório, 350 colaboradores e mais de 900 mil downloads no PyPI, e aparece integrado ao Dynamo da NVIDIA, ao armazenamento local de nó no Google Kubernetes Engine, ao vLLM em GPUs AMD Instinct e ao armazenamento de objetos da CoreWeave.
Não é a única falha na fila
No mesmo intervalo saiu a CVE-2026-107204, também 9,8, por ausência de autenticação em um endpoint /run_script que aceita script Python sem credencial, com fuga do __import__ protegido pelo objeto da aplicação FastAPI injetado. A classificação é CWE-306, falta de autenticação para função crítica, e na data a análise do NVD ainda estava pendente. Um conjunto de outros problemas de segurança foi reportado no projeto em 6 de outubro, ainda sem CVE e sem confirmação dos mantenedores. O padrão é o de um componente de infraestrutura de inferência que cresceu rápido com um modelo de confiança de rede interna.
O que fazer hoje
- Levantar onde há LMCache em modo multiprocesso e verificar se a 5555 está exposta além da rede de confiança.
- Trocar o bind roteável por
127.0.0.1onde a topologia permitir. - Regra de firewall ou NetworkPolicy limitando a porta aos pods de trabalho do vLLM que precisam dela. A JFrog avisa que isso reduz, mas não elimina: quem conecta, executa.
- Não rodar o processo como root. A imagem oficial faz isso por padrão.
- Acompanhar o projeto para a correção. A recomendação de fundo da JFrog é tirar o
pickle.loadsde dado de rede, autenticar o transporte com CURVE ou HMAC por mensagem e recusar bind roteável sem autenticação configurada.
Outros sinais do dia
- Causa
O pickle roda antes de o servidor olhar a requisição
A extensão msgpack de código 1 aponta para Deserialize, que chama pickle.loads na decodificação de argumentos. A validação vem depois.
- Exposição
O bind padrão é localhost, o risco vem do --host
A nota 9,8 vale para o endereço roteável que a documentação de múltiplos nós recomenda. Instalação de nó único não é alcançável de fora.
- Privilégio
A imagem oficial roda o processo como root
Execução confirmada em imagem oficial resulta em root dentro do contêiner, o que transforma o acesso em comprometimento do nó.
- Segunda falha
CVE-2026-107204, endpoint /run_script sem autenticação
Também 9,8, classificada como CWE-306. Aceita script Python sem credencial e escapa do __import__ protegido pelo objeto FastAPI.
- Detecção
Procure a porta 5555 em escuta e o argumento --host no manifesto
O inventário útil é o de pods e serviços de LMCache em modo multiprocesso. Em Kubernetes, começar pela NetworkPolicy ausente.
Fontes e aprofundamento
- JFrog Security Research · LMCache is vulnerable to Unauthenticated Remote Code Execution via Pickle Deserialization on the Multiprocess ZMQ Transport, aviso original, com versões afetadas, prova de conceito resumida, mitigações e a ausência de correção em 7 de outubro.
- Cyber Press · Critical LMCache Vulnerability Lets Unauthenticated Attackers Execute Code With Root Privileges, com o detalhe do fluxo de exploração e a orientação de inventário da porta 5555.
- LMCache · LMCache, a modular KV cache layer for LLM inference, para adoção, integrações com NVIDIA Dynamo, Google Kubernetes Engine, AMD e CoreWeave, e os números do projeto.
- vLLM · KV Cache Offloading, production-stack, documentação do uso de LMCache na pilha de produção do vLLM.
- Strix · CVE-2026-107204: LMCache Missing Authentication, com a segunda falha, o endpoint /run_script, a classificação CWE-306 e o estado da análise no NVD.