LMCache em modo multi‑processos revela vulnerabilidade de execução remota de código não verificada, afetando a camada de cache de modelos de grande escala

Em 8 de outubro de 2026, os meios de comunicação iThome e a equipa de investigação de segurança da JFrog (JFrog Security Research) publicaram simultaneamente um relatório detalhado que descreve a existência de uma vulnerabilidade crítica de execução remota de código não verificada no LMCache quando operado no modo multi‑processos, também conhecido como modo distribuído. Esta vulnerabilidade foi catalogada sob o identificador CVE‑2026‑105192 e recebeu, de acordo com a métrica CVSS versão 3.1, uma pontuação base de 9,8, o que a coloca na categoria de risco crítico.

Visão geral da vulnerabilidade

O defeito foi revelado publicamente pela equipa de investigação da JFrog (número interno JFSA‑2026‑001694382) no dia 7 de outubro de 2026 e afeta todas as versões do LMCache a partir da 0.3.9, incluindo a versão estável mais recente 0.5.5, a versão de teste 0.5.6rc3 e ainda os ramos de desenvolvimento que, até à data da divulgação, permanecem sem correção. A origem da vulnerabilidade reside no facto de o LMCache abrir, para partilha de cache KV entre processos, um socket ZeroMQ do tipo ROUTER que, por predefinição, escuta na porta TCP 5555 e não tem nenhum mecanismo de autenticação activado, como CURVE, ZAP, palavra‑passe ou HMAC.

Detalhes técnicos

Em cenários de implantação multi‑nó, o utilizador tem de especificar um endereço de rede roteável através do parâmetro `--host`. Quando esse parâmetro é usado, o socket ZeroMQ deixa de estar limitado ao endereço de loopback (localhost) e passa a ser acessível a partir de outras máquinas na rede. O LMCache utiliza o formato de codificação msgpack para a transmissão de dados; dentro desse formato, o código de extensão 1 é mapeado para a função `DeviceIPCWrapper.Deserialize`. Essa função, por sua vez, invoca diretamente a rotina padrão da biblioteca Python `pickle.loads`. A desserialização ocorre enquanto o servidor ainda está a processar o parâmetro `REGISTER_KV_CACHE`, antes de qualquer manipulador de pedidos ser acionado, permitindo que um atacante envie uma carga útil maliciosa em pickle que será executada como código Python arbitrário durante a fase de decodificação.

Fluxo de ataque

Um atacante precisa apenas de enviar uma mensagem msgpack especialmente criada para a porta 5555 aberta. Essa mensagem contém uma carga útil pickle que pode, por exemplo, gravar um ficheiro no sistema de ficheiros do contêiner, como `/tmp/zmq_pwn`. Após a escrita, a carga pode forçar a geração de um erro de tipo que será registado nos logs, servindo como prova de que o código foi executado no contexto do processo LMCache. As imagens oficiais de contêiner do LMCache são iniciadas por padrão com privilégios de root; assim, caso o exploit seja bem‑sucedido, o invasor obtém acesso root dentro do contêiner e pode, subsequentemente, comprometer outros serviços que partilhem o mesmo host físico.

Âmbito afetado

As versões vulneráveis compreendem a série 0.3.9, todas as versões 0.4.x e a série 0.5.x. As imagens de contêiner fornecidas oficialmente pela JFrog não contêm correções para este problema. Segundo a iThome, o socket ZeroMQ só é ativado quando o LMCache funciona como um serviço multi‑processos independente; se o LMCache for utilizado apenas como uma biblioteca interna dentro de um processo vLLM, o socket não é iniciado e, portanto, a vulnerabilidade não fica exposta. Por predefinição, o socket ZeroMQ está ligado ao localhost, o que impede o acesso direto de um atacante remoto, a menos que um administrador altere manualmente o parâmetro `--host` para um endereço IP que seja roteável fora da máquina.

Mitigações e recomendações

A JFrog recomenda que os operadores limitem imediatamente o endereço de ligação do serviço multi‑processos ao localhost e que bloqueiem a porta TCP 5555 através de firewalls ou políticas de rede de cluster. Até que uma correção oficial seja disponibilizada, deve‑se evitar o uso de endereços IP externos no parâmetro `--host`. A longo prazo, sugere‑se redesenhar a camada de transporte para eliminar a dependência de pickle na desserialização de dados recebidos da rede, adotando um formato de serialização seguro, como JSON ou protobuf, e implementar mecanismos de autenticação no socket ZeroMQ, como CURVE ou HMAC, para garantir que apenas clientes autorizados possam comunicar com o serviço.

Seguimento e perspetivas

Até 8 de outubro de 2026, o fornecedor ainda não lançou nenhuma versão corrigida nem atualizou as imagens de contêiner para remover a desserialização insegura. O calendário de lançamento de uma correção permanece indefinido, e não está claro se distribuições de terceiros já incorporaram medidas de mitigação. Caso as organizações tenham mantido a configuração padrão de ligação ao localhost ou isolado os contêineres de redes não confiáveis, não estarão expostas a ataques diretos de agentes externos. Contudo, utilizadores internos ou máquinas já comprometidas dentro da rede interna ainda podem explorar a vulnerabilidade para obter privilégios de root dentro do contêiner e, potencialmente, escalar o ataque a outros componentes do sistema.