PoeLLM infecta 3.400 servidores de IA expostos

A infraestrutura utilizada para executar modelos de inteligência artificial está se tornando um alvo cada vez mais interessante para cibercriminosos. Servidores com grande capacidade computacional, APIs expostas, credenciais de provedores de LLM e ferramentas instaladas rapidamente para testes ou produção criaram uma nova superfície de ataque que muitas organizações ainda não monitoram com o mesmo rigor aplicado aos seus servidores tradicionais.

Uma nova campanha acompanhada pela Black Lotus Labs, divisão de inteligência de ameaças da Lumen Technologies, deixa esse problema bastante evidente.

Batizado de PoeLLM, o malware já atingiu mais de 3.400 servidores, principalmente nos Estados Unidos e na Europa Ocidental. No pico da operação, mais de 800 sistemas comprometidos estiveram ativos em um único dia. A campanha está em operação pelo menos desde abril de 2026 e tem como alvos ambientes executando ferramentas como LiteLLM, Ollama, Gotenberg e Gitea, além de haver evidências de interesse em dispositivos Ivanti Sentry.

Mas o PoeLLM não transforma essas máquinas apenas em mineradores de criptomoedas.

Depois de comprometer um servidor, os operadores também reutilizam a vítima para procurar novos sistemas vulneráveis e lançar novas tentativas de exploração. Na prática, cada novo servidor infectado pode ajudar a ampliar a própria campanha.

Neste artigo do Blog Dolutech, vamos entender como o PoeLLM funciona, por que servidores de inteligência artificial estão se tornando alvos valiosos e quais medidas as empresas devem adotar para proteger suas infraestruturas de IA.

O que é o malware PoeLLM?

O PoeLLM é um malware Linux observado em uma campanha de cryptojacking e propagação automatizada acompanhada pela Black Lotus Labs desde abril de 2026.

Os pesquisadores chegaram à infraestrutura da operação enquanto investigavam atividades relacionadas a uma vulnerabilidade do Ivanti Sentry. A partir dessa análise, identificaram servidores comprometidos comunicando-se com uma infraestrutura que posteriormente foi associada ao PoeLLM.

O malware analisado aparece como um arquivo ELF chamado libgcrypt e incorpora diversas funções.

Além dos mineradores de criptomoedas XMRig e Iron, o código possui funcionalidade de shell remoto, scanning HTTP e HTTPS e mecanismos para lançar explorações contra outros sistemas vulneráveis.

Isso faz com que a campanha vá além do cryptojacking tradicional.

Em vez de simplesmente comprometer uma máquina, utilizar sua CPU ou GPU e permanecer escondido minerando criptomoedas, o PoeLLM também transforma a vítima em parte da infraestrutura utilizada para encontrar o próximo alvo.

A Black Lotus Labs observou servidores infectados sendo utilizados como scanners e como servidores de exploração. Mais recentemente, alguns bots também começaram a direcionar tráfego para SSH e outros portais de autenticação, embora os pesquisadores avaliem que essa possível estrutura de brute force distribuído ainda esteja em estágio inicial.

Mais de 3.400 servidores já foram afetados

O tamanho da operação é um dos aspectos que chama atenção.

Segundo a versão atualizada da pesquisa, o PoeLLM já afetou mais de 3.400 servidores, com a maior concentração de vítimas localizada nos Estados Unidos e na Europa Ocidental.

No período de maior atividade, mais de 800 servidores infectados chegaram a permanecer ativos simultaneamente em um único dia.

A operação começou de maneira relativamente discreta.

O primeiro commit conhecido relacionado ao mecanismo de comunicação utilizado pelo malware ocorreu em 13 de abril de 2026. Em maio, a infraestrutura passou a executar scanning e exploração em uma escala maior.

Durante junho, a Black Lotus Labs já observava milhares de servidores envolvidos na campanha.

Esse comportamento mostra como uma operação inicialmente pequena pode ganhar escala quando cada vítima comprometida passa a colaborar com a descoberta e exploração de outras máquinas.

O detalhe mais curioso: um poema controla o endereço do C2

Um dos mecanismos mais interessantes tecnicamente no PoeLLM está na forma utilizada para localizar seus servidores de Command and Control, ou C2.

Em vez de simplesmente armazenar um endereço IP fixo dentro do malware, o PoeLLM consulta um arquivo hospedado em um repositório no GitHub.

Dentro desse arquivo existe um poema chamado “On the Nature of Connection”.

O malware procura quatro palavras específicas no texto. Em seguida, compara essas palavras com um dicionário embutido no próprio binário e transforma cada uma delas em um número.

Os quatro números resultantes formam um endereço IPv4.

Ou seja, o poema funciona como uma espécie de mecanismo externo de descoberta do servidor C2.

Como o atacante troca o servidor C2

A técnica permite que o operador altere a infraestrutura sem precisar modificar diretamente todas as cópias do malware instaladas nas vítimas.

Quando um novo C2 precisa ser utilizado, determinadas palavras do poema são alteradas no GitHub.

Na próxima consulta, as máquinas infectadas extraem as novas palavras, aplicam novamente o dicionário e calculam o novo endereço IP.

A Black Lotus Labs identificou 11 alterações no poema desde o primeiro commit conhecido.

Os pesquisadores mapearam ao todo 12 endereços IP utilizados como C2 durante a campanha, sendo que três continuavam ativos no momento da publicação da análise em 7 de outubro.

É uma técnica relativamente simples, mas interessante do ponto de vista de resiliência.

Bloquear apenas um endereço IP pode não ser suficiente se o atacante conseguir alterar rapidamente a referência utilizada pelas máquinas já infectadas.

LiteLLM aparece no centro da cadeia de exploração

Um dos componentes mais importantes da investigação envolve o LiteLLM, uma plataforma utilizada como AI Gateway para centralizar o acesso a diferentes provedores e modelos de linguagem.

A própria documentação do LiteLLM mostra o quanto esse tipo de componente pode ser sensível: o gateway pode centralizar chaves de provedores, autenticação de usuários, acesso a modelos e integrações com servidores MCP.

Durante a análise de uma amostra do PoeLLM, a Black Lotus Labs encontrou código direcionando requisições para um endpoint relacionado ao mecanismo de testes MCP do LiteLLM.

O caminho observado estava relacionado à vulnerabilidade CVE-2026-42271.

CVE-2026-42271

A CVE-2026-42271 é uma vulnerabilidade de command injection existente em versões do LiteLLM entre 1.74.2 e 1.83.6.

Dois endpoints destinados a testar uma configuração de servidor MCP aceitavam parâmetros relacionados ao transporte stdio, incluindo comando, argumentos e variáveis de ambiente.

Quando utilizados, esses parâmetros podiam fazer com que o LiteLLM executasse um subprocesso no servidor.

Originalmente, o problema exigia uma chave válida do proxy. O problema, entretanto, era que usuários com privilégios reduzidos também poderiam chegar à funcionalidade vulnerável.

A falha recebeu pontuação CVSS 8.7 no CVSS v4 e foi corrigida no LiteLLM 1.83.7.

A vulnerabilidade também passou a constar no catálogo de vulnerabilidades conhecidas como exploradas da CISA em junho de 2026, demonstrando que não estamos falando apenas de uma possibilidade teórica de exploração.

De falha autenticada a RCE sem autenticação

Existe uma nuance importante nesse caso.

A CVE-2026-42271, sozinha, não deve ser simplesmente descrita como uma vulnerabilidade de RCE sem autenticação.

A exploração original exige autenticação.

Pesquisadores da Horizon3 demonstraram, entretanto, que ela pode ser combinada com outra vulnerabilidade, a CVE-2026-48710, conhecida como BadHost, presente no framework Starlette.

Nesse cenário, uma inconsistência na validação do cabeçalho HTTP Host pode fazer com que verificações baseadas em request.url.path interpretem um caminho diferente daquele realmente processado pelo roteador da aplicação.

Com isso, determinados mecanismos de autorização podem ser contornados.

Em implantações vulneráveis do LiteLLM, a Horizon3 confirmou que a CVE-2026-48710 pode ser utilizada para contornar o requisito de autenticação da CVE-2026-42271.

O resultado da cadeia é uma execução remota de comandos sem credenciais no processo do LiteLLM.

Segundo a Horizon3, uma exploração bem-sucedida pode permitir acesso às credenciais de provedores de modelos, roubo de chaves e secrets armazenados pelo gateway e criação de caminhos para movimentação lateral em componentes conectados à infraestrutura de IA.

A correção recomendada é utilizar LiteLLM 1.83.7 ou superior e garantir que a dependência Starlette esteja em uma versão corrigida, 1.0.1 ou superior para o problema BadHost.

Ollama também aparece entre os servidores comprometidos

A investigação da Black Lotus Labs encontrou diversas vítimas executando Ollama, além de LiteLLM, Gotenberg e Gitea.

Aqui é importante fazer uma distinção.

O relatório detalha especificamente a exploração do endpoint vulnerável do LiteLLM na amostra analisada do PoeLLM. A presença de servidores Ollama entre as vítimas não significa, por si só, que a mesma vulnerabilidade ou que uma vulnerabilidade específica do Ollama tenha sido utilizada em todos esses comprometimentos.

O ponto mais amplo é outro: serviços de IA expostos diretamente à internet estão sendo encontrados e selecionados como alvos.

Isso reforça uma prática que muitas equipes ainda negligenciam ao implementar rapidamente ferramentas de inteligência artificial internas.

Uma API funcionar na porta configurada não significa que essa API deva estar acessível publicamente.

Gotenberg mostra como uma configuração simples pode aumentar o risco

O mesmo cenário aparece no Gotenberg, ferramenta de conversão de documentos para PDF encontrada em centenas dos servidores relacionados à campanha.

A própria documentação oficial do projeto é explícita:

o Gotenberg não deve ser exposto diretamente à internet e deve ser tratado de forma semelhante a um banco de dados, mantendo-o atrás de um firewall.

Por padrão, um container publicado de maneira inadequada pode tornar sua porta acessível externamente.

É um exemplo importante porque mostra que nem sempre o problema começa com uma sofisticada zero-day.

Muitas vezes o atacante começa simplesmente procurando um serviço que nunca deveria estar visível publicamente.

Por que servidores de IA são alvos tão interessantes?

O crescimento da infraestrutura de IA criou um novo tipo de ativo de alto valor.

Primeiro existe a capacidade computacional.

Servidores destinados à inferência ou treinamento normalmente possuem GPUs e CPUs significativamente mais poderosas do que servidores convencionais. Para uma operação de mineração de criptomoedas, isso representa um recurso muito atraente.

Mas o risco não termina no hardware.

Um AI Gateway pode armazenar ou ter acesso a:

credenciais de provedores de LLM, tokens de API, bases de conhecimento, integrações MCP, bancos de dados, sistemas internos e informações enviadas pelos usuários aos modelos.

A própria Black Lotus Labs alerta que servidores de IA devem ser considerados interessantes tanto pela capacidade computacional quanto pelos dados e acessos existentes nesses ambientes.

Isso muda a maneira como devemos pensar a segurança da IA.

A proteção não pode ficar restrita ao modelo, aos prompts ou a ataques como prompt injection.

Existe uma infraestrutura inteira por trás da IA que continua sujeita aos mesmos problemas clássicos da cibersegurança: software vulnerável, APIs expostas, credenciais mal protegidas, falta de segmentação, dependências desatualizadas e ausência de monitoramento.

A vítima também passa a atacar outras vítimas

Talvez o aspecto mais importante do PoeLLM esteja aqui.

Depois da infecção, o servidor comprometido não serve apenas para mineração.

Ele passa a atuar como um novo nó da operação.

A Black Lotus Labs observou tráfego significativo originado das próprias vítimas em direção às portas 3000 e 4000, normalmente associadas no contexto investigado a Gotenberg e LiteLLM.

As máquinas infectadas eram utilizadas para descobrir novos sistemas e auxiliar na exploração desses alvos.

Isso cria um ciclo:

descoberta do serviço → exploração → instalação do malware → mineração → scanning → descoberta de novas vítimas.

Consequentemente, o endereço IP utilizado para atacar outra empresa pode pertencer a uma organização legítima que também foi comprometida.

Essa característica dificulta análises baseadas apenas em reputação de IP e reforça a necessidade de correlacionar comportamento, tráfego, processos e indicadores de comprometimento.

Indicadores de comprometimento do PoeLLM

A Black Lotus Labs publicou uma lista pública de IoCs relacionados à campanha.

Em 7 de outubro de 2026, três endereços C2 continuavam listados como ativos:

92.119.164[.]50

103.249.201[.]108

178.128.14[.]204

Os pesquisadores também observaram sistemas infectados realizando beacon para portas como 3778, 5001, 5002 e 9999, enquanto outras partes da infraestrutura estiveram relacionadas a conexões com serviços utilizados para mineração de criptomoedas.

Esses IoCs não devem ser utilizados isoladamente para concluir que um sistema foi comprometido. Eles servem como pontos de partida para investigação e devem ser correlacionados com logs de rede, processos, conexões de saída e telemetria de endpoint.

Como mitigar o risco do PoeLLM

Empresas que utilizam infraestrutura própria de inteligência artificial deveriam aproveitar esse caso para revisar imediatamente sua superfície de ataque.

Atualize o LiteLLM

Instalações afetadas pela CVE-2026-42271 devem ser atualizadas para LiteLLM 1.83.7 ou superior.

Também é necessário validar a árvore de dependências e garantir que versões vulneráveis do Starlette relacionadas à CVE-2026-48710 não permaneçam instaladas.

Quando uma atualização imediata não for possível, a recomendação dos pesquisadores inclui bloquear o acesso aos endpoints MCP de teste afetados e restringir a conectividade somente a segmentos confiáveis.

Não exponha APIs de IA diretamente à internet

LiteLLM, Ollama, interfaces administrativas, servidores MCP e outras APIs internas não deveriam ficar publicamente acessíveis apenas porque isso facilita um laboratório ou implantação inicial.

Utilize firewall, VPN, Zero Trust Network Access, reverse proxy ou API Gateway com autenticação adequada.

Serviços que não precisam de acesso público devem simplesmente não possuir acesso público.

Segmente a infraestrutura de IA

Um servidor que executa um modelo não deveria possuir acesso irrestrito a toda a rede corporativa.

Crie segmentos específicos para workloads de IA e aplique políticas de least privilege.

Se um gateway for comprometido, o atacante não deveria conseguir utilizar esse servidor como ponto de partida para acessar bancos de dados, sistemas administrativos, ambientes de produção ou serviços internos sem controles adicionais.

Proteja API keys e secrets

AI Gateways frequentemente concentram credenciais extremamente valiosas.

Chaves de OpenAI, Anthropic, Google, Azure, AWS ou outros provedores podem permitir consumo financeiro, acesso a modelos e, dependendo da integração existente, acesso a outros recursos.

Secrets devem ser armazenados de maneira apropriada, rotacionados periodicamente e nunca mantidos desnecessariamente em arquivos de configuração, imagens de containers ou repositórios.

Caso exista evidência de comprometimento de um gateway, a rotação dessas credenciais deve fazer parte do processo de resposta.

Monitore consumo inesperado de CPU e GPU

Cryptominers costumam produzir um indicador que pode ser detectado rapidamente: utilização incomum e sustentada de recursos.

Picos inesperados de CPU ou GPU em servidores que deveriam estar ociosos ou executando inferências previsíveis devem gerar alertas.

O mesmo vale para novos processos relacionados a mineração, conexões para pools desconhecidos e utilização computacional fora do padrão normal da aplicação.

Monitore conexões de saída

O controle de egress continua extremamente subestimado.

Servidores internos não precisam necessariamente conseguir iniciar conexões arbitrárias para qualquer endereço da internet.

Políticas de saída, DNS monitoring, proxy e análise de NetFlow podem ajudar a detectar servidores comprometidos comunicando-se com C2s, pools de mineração e outros nós da infraestrutura atacante.

Inclua IA no Attack Surface Management

Se uma equipe implantou Ollama, LiteLLM, um servidor MCP ou outro serviço de IA, esse ativo precisa entrar automaticamente no inventário de segurança.

Ele deve receber:

patch management, vulnerability scanning, gestão de exposição externa, monitoramento, logs, EDR quando aplicável e revisão periódica de configuração.

A infraestrutura de IA não pode existir como uma espécie de “laboratório permanente” fora dos processos de segurança da empresa.

O PoeLLM deixa uma mensagem importante para empresas

Existe uma tendência compreensível de associar segurança de inteligência artificial apenas aos modelos.

Falamos de jailbreaks, prompt injection, data poisoning, vazamento de prompts e comportamento de agentes.

Esses problemas são importantes.

Mas o PoeLLM mostra uma realidade muito mais convencional e, ao mesmo tempo, perigosa.

Antes de atacar o modelo, o criminoso pode simplesmente atacar o servidor onde o modelo está sendo executado.

A aplicação pode possuir uma vulnerabilidade.

A API pode estar exposta.

O container pode ter sido publicado em 0.0.0.0.

Um gateway pode concentrar secrets de dezenas de modelos.

Um servidor com GPU pode estar disponível para mineração.

E um ambiente comprometido pode posteriormente servir como infraestrutura para atacar outras empresas.

Para nós, esse é um dos principais aprendizados dessa campanha.

A adoção de inteligência artificial está expandindo rapidamente a superfície de ataque corporativa, e os controles tradicionais de segurança continuam sendo tão necessários quanto antes.

Na verdade, eles passam a ser ainda mais importantes.

Conclusão

O PoeLLM representa bem uma mudança que deve ganhar cada vez mais espaço no cenário de ameaças: a infraestrutura de inteligência artificial passou a ser um alvo de alto valor.

Mais de 3.400 servidores já foram associados à campanha acompanhada pela Black Lotus Labs. Máquinas comprometidas foram utilizadas para mineração de criptomoedas, scanning, exploração e descoberta de novas vítimas.

A operação ainda utiliza uma técnica incomum para encontrar sua infraestrutura C2, transformando palavras de um poema hospedado no GitHub em endereços IP, enquanto vulnerabilidades conhecidas em componentes como LiteLLM oferecem caminhos para comprometimento de ambientes expostos.

Nesse artigo do Blog Dolutech, o ponto que queremos reforçar é simples: colocar um LLM dentro da infraestrutura não transforma aquele servidor em um ativo diferente das demais aplicações críticas da empresa.

Ele precisa de patching, segmentação, controle de acesso, observabilidade, proteção de secrets e gestão contínua da superfície de ataque.

A IA pode ser nova.

Os erros que permitem que atacantes entrem continuam sendo, em muitos casos, bastante conhecidos.