Falha critica sem patch no LMCache permite execucao remota de codigo em servidores de cache de LLM
O LMCache, componente open-source usado para acelerar servidores de LLM como o vLLM, tem uma falha critica (CVE-2026-105192, CVSS 9.8) em seu modo multiprocess: o socket ZeroMQ que recebe mensagens entre workers e o servidor de cache nao exige autenticacao e desserializa dados com pickle antes de qualquer validacao de tipo. Um unico pacote de rede malicioso basta para executar codigo arbitrario com os privilegios do processo, que em containers oficiais costuma ser root. Nao ha versao corrigida disponivel; a unica mitigacao e nao expor o servidor multiprocess em endereco roteavel.
A vulnerabilidade foi descoberta por Yuval Moravchick, da JFrog Security Research, e afeta todas as versoes do LMCache entre a 0.3.9 (outubro de 2025) e a 0.5.5, incluindo os release candidates 0.5.6 e a branch de desenvolvimento. O LMCache existe para resolver um problema concreto de performance em inferencia de LLM: reaproveitar o cache de KV (key-value) entre requisicoes e entre instancias do vLLM, evitando recomputar o contexto de prompts repetidos. Para isso, em deployments distribuidos, ele pode rodar em modo multiprocess, onde um servidor de cache independente e acessado pelos workers do LLM via ZeroMQ, uma biblioteca de mensageria leve e rapida, mas que nao implementa autenticacao por padrao.
O problema tecnico central e a combinacao de duas decisoes de design inseguras: o socket ZeroMQ aceita conexoes de qualquer origem que alcance a porta, e as mensagens recebidas sao desserializadas com o modulo pickle da linguagem Python antes de qualquer verificacao de schema ou tipo. O pickle do Python nao foi desenhado para processar dados nao confiaveis: seu protocolo de desserializacao permite instanciar classes arbitrarias e invocar metodos durante o processo de carregamento do objeto, o que na pratica equivale a um canal de execucao de codigo. Um atacante que envie um payload pickle malicioso para a porta exposta do servidor de cache obtem execucao de codigo imediata, sem precisar de credenciais, exploracao de memoria ou qualquer interacao do usuario.
O fator que eleva drasticamente o risco pratico e a exposicao tipica em producao: o modo multiprocess so se torna perigoso quando o operador vincula o servidor a um endereco roteavel em vez de localhost, e e exatamente isso que os manifestos oficiais de deployment em Kubernetes fazem por padrao, para permitir que workers em pods diferentes conversem com o cache compartilhado. Ou seja, a configuracao recomendada pela proria documentacao do projeto para uso distribuido e a mesma que abre a porta de ataque. Como o pickle malicioso executa com os privilegios do processo LMCache -- frequentemente root dentro de containers oficiais -- um unico host comprometido pode servir de pivo para o restante do cluster de inferencia, incluindo os pesos de modelo e qualquer segredo acessivel ao pod.
A ausencia de patch, somada ao fato de que seis relatos adicionais de seguranca (sem CVE confirmado ainda) apontam problemas semelhantes de acesso nao autenticado a dados em cache, sugere que o LMCache nao foi desenhado originalmente com um modelo de ameaca que considerasse rede nao confiavel entre workers e cache. Para quem opera infraestrutura de inferencia com vLLM e LMCache, a recomendacao imediata e isolar a rede do servidor multiprocess (localhost ou rede de cluster estritamente confiavel, nunca endereco roteavel publicamente) e tratar qualquer exposicao atual como incidente potencial, dado que a janela de exploracao permanece aberta sem correcao oficial.