PoeLLM: publicar um servidor de IA também publica uma superfície de ataque

A Black Lotus Labs acompanha uma campanha com o malware PoeLLM que transforma servidores comprometidos em mineradores, scanners e plataformas de exploração.[4] O levantamento atualizado citado pelo BleepingComputer aponta mais de 3.400 servidores comprometidos e até 800 sistemas infectados ativos em um dia.[4] São números da pesquisa, não uma contagem universal de infraestrutura de IA vulnerável.

O que muda para quem desenvolve

Entre os serviços expostos encontrados nos sistemas atingidos estão LiteLLM, Ollama, Gotenberg e Gitea.[4] A reportagem não afirma que toda instalação desses produtos seja vulnerável nem que todos os comprometimentos compartilhem a mesma falha.[4]

Um caminho descrito envolve endpoints de teste MCP do LiteLLM: a CVE-2026-42271 pode ser combinada com a CVE-2026-48710 para execução remota sem login, segundo a análise citada da Horizon3.ai.[4] Minha leitura é que interfaces auxiliares merecem a mesma revisão das rotas consideradas principais. Um endpoint criado para testar uma integração não deve receber exposição pública por conveniência.

Há outro detalhe operacional: o malware procura palavras em um poema guardado num arquivo CSS no GitHub e usa um dicionário embutido para obter o endereço de comando.[4] Isso sugere uma pergunta útil para observabilidade: por que este processo precisa consultar esse conteúdo externo? Conhecer a finalidade do tráfego ajuda mais que reconhecer apenas nomes de bibliotecas.

Como aplicar

Faça um inventário das portas publicadas e ligue cada uma a uma função de produto. Para cada serviço de inferência, proxy de LLM ou conversão, documente quem pode conectar, como é autenticado e quais ferramentas ficam acessíveis depois dessa autenticação. Remova exposição que não tenha uma necessidade explícita.

Em um ambiente autorizado, teste duas condições com requisições benignas: uma origem permitida consegue usar o serviço e uma origem não autorizada é recusada. Verifique separadamente as interfaces de administração, depuração e teste. O sucesso da rota principal não comprova proteção das demais.

Para a operação, proponho acompanhar consumo de CPU e GPU, processos inesperados e destinos de rede fora da linha de base. A campanha observada inclui shell remoto, mineradores XMRig e Iron e propagação para outros alvos.[4] Portanto, consumo anormal não deve ser tratado apenas como um problema de capacidade.

Se houver sinais de comprometimento, preserve evidências e investigue o ambiente antes de devolver a porta ao ar. Fechar acesso externo e reiniciar um processo não demonstra remoção de persistência.

Cuidados e limites

O total inicial de 2.100 servidores foi corrigido para 3.400 após atualização da pesquisa.[4] A hipótese de um operador italiano tem confiança moderada e não constitui atribuição definitiva.[4]

Não use o número de vítimas para condenar um produto inteiro. Também não interprete autenticação adicionada depois do incidente como recuperação comprovada. A decisão de engenharia é separar prevenção, detecção e reconstrução de confiança. Cada uma exige evidência própria.

Fonte

[4] Fonte: BleepingComputer