LMCache: cache compartilhado não pode herdar confiança da rede

A JFrog divulgou a CVE-2026-105192 no LMCache: uma mensagem preparada pode executar código sem autenticação no servidor usado pelo modo multiprocessos.[2] A nota CVSS 9,8 corresponde ao cenário com serviço acessível por endereço roteável.[2] Na reportagem de 7 de outubro de 2026, ainda não havia lançamento corrigido.[2]

O que muda para quem desenvolve

O defeito está na desserialização com pickle de argumentos recebidos por ZeroMQ, antes da verificação do tipo da mensagem.[2] Nas imagens oficiais examinadas pela JFrog, o processo executava como root.[2] A conclusão de projeto é importante: validar uma mensagem depois de uma operação capaz de executar código não protege essa operação.

A exposição depende da arquitetura. Por padrão, o servidor multiprocessos escuta em localhost; o exemplo Kubernetes analisado, porém, o inicia em todas as interfaces.[2] A integração no mesmo processo do vLLM, sem abrir esse servidor, não oferece esse caminho de ataque.[2]

Minha análise é que uma otimização de inferência pode introduzir uma nova fronteira de confiança. Antes de avaliar apenas taxa de acerto do cache ou economia de processamento, é preciso saber quem consegue enviar dados ao componente. O rótulo de serviço interno não deve dispensar esse levantamento.

Como aplicar

Monte uma matriz com versão, modo de operação, interface de escuta, origens autorizadas e privilégios do processo. Preencha a matriz a partir da configuração efetiva, não somente do manifesto que a equipe acredita ter implantado.

Em ambiente de teste autorizado, verifique conectividade a partir de três origens: o processo consumidor, uma carga que não deveria acessar o cache e uma origem externa ao cluster. Use somente testes de conexão, sem enviar objetos maliciosos. O resultado esperado deve ser definido antes: acesso onde há necessidade e bloqueio onde não há.

Enquanto não houver uma correção verificada para a implantação, a recomendação descrita é evitar endereço roteável ou limitar acesso ao host local ou a uma rede confiável.[2] Como medida adicional de redução de impacto, proponho remover privilégios desnecessários e separar o cache de credenciais de outros serviços. Isso não corrige a desserialização.

Para futuras interfaces, trate os dados recebidos como não confiáveis desde a entrada. Prefira contratos explícitos e formatos que não dependam de executar lógica durante a leitura. Autenticação e autorização devem preceder a interpretação perigosa de dados.

Cuidados e limites

O intervalo afetado informado inclui 0.3.9 a 0.5.5, candidatos da 0.5.6 e a branch de desenvolvimento examinada.[2] A correção da falha relacionada no vLLM 0.30.0 não corrige esta RCE do LMCache.[2]

Restringir a rede reduz a superfície, mas uma máquina que conserve acesso ao socket ainda pode explorar o problema.[2] O aviso também não oferece um método retrospectivo para determinar exploração.[2] Portanto, conexão bloqueada hoje não prova ausência de ataque ontem, e atualização de um componente vizinho não prova correção do serviço vulnerável.

Fonte

[2] Fonte: The Hacker News