Modo multiprocessos do LMCache revela vulnerabilidade de execução remota de código não verificada, afetando camada de cache de inferência de grandes…

Em 8 de outubro de 2026, os veículos de imprensa iThome e JFrog Security Research publicaram simultaneamente um relatório detalhado indicando que o componente LMCache apresenta, quando operado no modo multiprocessos (também conhecido como distribuído), uma vulnerabilidade de execução remota de código que não foi devidamente verificada (identificada como CVE‑2026‑105192). De acordo com a avaliação do padrão CVSS versão 3.1, a pontuação base atribuída a essa falha é 9,8, o que a classifica como de gravidade crítica.

Visão geral da vulnerabilidade

A falha foi divulgada oficialmente pela equipe de pesquisa da JFrog, sob o identificador interno JFSA‑2026‑001694382, em 7 de outubro de 2026. Ela afeta todas as versões do LMCache lançadas a partir da 0.3.9, incluindo a série estável mais recente 0.5.5, a versão de teste 0.5.6rc3 e também os ramos de desenvolvimento que ainda não receberam correções. A origem da vulnerabilidade está no socket ZeroMQ do tipo ROUTER que o LMCache habilita para permitir o compartilhamento de KV‑cache entre processos diferentes; por padrão, esse socket escuta na porta TCP 5555 e não ativa nenhum mecanismo de autenticação, como CURVE, ZAP, senha ou HMAC, deixando a comunicação aberta a acessos não autorizados.

Detalhes técnicos

Em cenários de implantação multinódo, o operador deve especificar um endereço que possa ser roteado por meio do parâmetro de linha de comando `--host`. Ao fazer isso, o socket ZeroMQ deixa de estar restrito ao endereço de loopback (localhost) e passa a aceitar conexões provenientes de outras máquinas na rede. O LMCache utiliza o formato de serialização msgpack para codificar os dados transmitidos; especificamente, o código de extensão 1 definido pelo msgpack é mapeado para a função `DeviceIPCWrapper.Deserialize`. Essa função, por sua vez, invoca diretamente o método `pickle.loads` da biblioteca padrão do Python, sem aplicar nenhuma validação prévia ao conteúdo recebido. Essa desserialização ocorre enquanto o servidor ainda está processando o parâmetro `REGISTER_KV_CACHE`, antes de encaminhar a requisição a qualquer manipulador de aplicação, o que permite que um atacante insira um payload pickle malicioso que será executado como código Python arbitrário durante a fase de decodificação.

Fluxo de ataque

Para explorar a vulnerabilidade, o invasor precisa apenas enviar uma mensagem especialmente formatada em msgpack para a porta 5555 que está aberta. O payload pickle incluído nessa mensagem pode, por exemplo, gravar um arquivo arbitrário no sistema de arquivos do contêiner, como `/tmp/zmq_pwn`. Em seguida, o código malicioso pode forçar a geração de uma mensagem de log contendo um erro de tipo, servindo como prova de que o código foi efetivamente executado dentro do contexto do processo LMCache. Vale notar que a imagem oficial do contêiner do LMCache é configurada para iniciar o serviço com privilégios de usuário root por padrão; assim, caso a exploração seja bem‑sucedida, o atacante obtém acesso root dentro do contêiner e pode, a partir daí, comprometer outros serviços que estejam sendo executados na mesma máquina física ou virtual.

Escopo afetado

As versões do LMCache que estão dentro do escopo de vulnerabilidade compreendem as séries 0.3.9, 0.4.x e 0.5.x. Todas as imagens de contêiner fornecidas oficialmente pela JFrog permanecem sem a aplicação de correções para essa falha. De acordo com a análise da iThome, a porta ZeroMQ só é ativada quando o LMCache funciona como um serviço multiprocessos independente; caso o LMCache seja utilizado exclusivamente como um componente interno dentro do processo vLLM, a porta não é iniciada, o que impede a exposição da vulnerabilidade. Por padrão, o ZeroMQ está configurado para escutar apenas no endereço localhost, o que impede que um atacante remoto acesse a porta diretamente, a menos que um administrador altere manualmente o parâmetro `--host` para um endereço que seja roteável fora da máquina local.

Mitigação e recomendações

A JFrog recomenda, como medida imediata, restringir o endereço de vinculação do serviço multiprocessos ao localhost, impedindo que o socket ZeroMQ aceite conexões externas. Além disso, sugere-se bloquear a porta TCP 5555 por meio de regras de firewall ou políticas de rede do cluster, de modo a eliminar o vetor de ataque externo. Até que um patch de segurança oficial seja disponibilizado, é fortemente aconselhado que os operadores evitem especificar um endereço IP que possa ser roteado externamente no parâmetro `--host`. No horizonte de longo prazo, a camada de transporte deve ser redesenhada para eliminar o uso de pickle na desserialização de dados de rede não verificados, adotando um formato de serialização que ofereça garantias de segurança, e o socket ZeroMQ deve ser configurado para exigir autenticação, utilizando mecanismos como CURVE ou HMAC.

Desenvolvimentos futuros e perspectivas

Até a data de 8 de outubro de 2026, o fornecedor ainda não havia lançado nenhuma versão corretiva nem disponibilizado imagens de contêiner atualizadas que desativem a desserialização insegura; o cronograma previsto para a liberação de um patch permanece indefinido. Também não está claro se distribuições de terceiros já incorporaram medidas de mitigação ou backports para corrigir a vulnerabilidade. Ambientes que mantiveram a configuração padrão de vínculo ao localhost ou que isolaram o contêiner de redes não confiáveis não estão expostos a ameaças diretas de atacantes remotos. Contudo, usuários internos mal-intencionados ou máquinas que já tenham sido comprometidas podem ainda explorar a falha para obter privilégios máximos dentro do contêiner, representando um risco significativo de escalada de privilégios.