Pluto Security relata nova onda de malware no Hugging Face

Em análise publicada em 29 de outubro de 2026, a Pluto Security relatou uma segunda onda de repositórios maliciosos no Hugging Face após a remoção de contas ligadas à primeira. O código podia iniciar um minerador de criptomoedas durante o carregamento do modelo, quando a opção trust_remote_code=True permitia executar Python do repositório. A Pluto também detalhou rastros que equipes poderiam procurar em hosts que carregaram esses modelos.

O que os números da campanha contabilizam

Até 28 de outubro de 2026, a Pluto Security contabilizou 31 repositórios principais em duas ondas, distribuídos por sete contas, além de 13 modelos vinculados. Os totais de downloads foram diferentes para cada grupo:

Somados, são 32.376 downloads em 44 repositórios, contando os modelos vinculados. Os 31 repositórios principais não incluem esses 13 modelos. Download não é sinônimo de usuário único nem de máquina infectada: a contagem não informa quantas pessoas carregaram os modelos ou quantos hosts executaram o código.

A Pluto relatou que a segunda onda surgiu em novas contas poucos dias depois das remoções da primeira. Em uma publicação de 29 de outubro, o BleepingComputer disse ter examinado uma cópia quase idêntica de qwen2-tiny, enviada em 25 de outubro pela conta htt0118, e encontrado o mesmo minerador e um shell reverso. Esse exame foi relatado naquele momento; não determina a situação posterior do repositório.

Como o código Python era executado ao carregar o modelo

Com trust_remote_code=True, o carregador podia importar e executar o módulo Python indicado pela configuração do repositório enquanto carregava o modelo. As instruções no nível do módulo são executadas durante a importação, antes de o carregador devolver a classe do modelo. Segundo a Pluto Security, o código rodava com os privilégios do processo que fazia o carregamento.

No repositório analisado MENXIANGYU/qwen2-tiny, a Pluto informou que o arquivo model.safetensors tinha 42 bytes e não continha tensores. O comportamento malicioso estava no código Python do repositório, não nos pesos do modelo. Assim, o risco descrito dependia da execução do código remoto durante a carga, e não de um arquivo de pesos adulterado.

Rastros de persistência e recursos de variantes específicas

A Pluto descreveu um minerador chamado syscore.bin, iniciado da memória e disfarçado com o nome de processo [kworker/u20:1]. Em uma versão analisada, um script em /tmp/.cch/svc.py monitorava o minerador e o reiniciava a cada 120 segundos se ele parasse. O código também alterava arquivos de inicialização do shell para manter a execução.

Esses caminhos e comportamentos ajudam a orientar a investigação, mas não eram todos comuns a cada repositório. A Pluto identificou shells reversos em versões específicas, incluindo qwen2-tiny-5, qwen2-tiny-6 e qwen2-tiny-9, que se conectavam a 212.32.253.3 pelas portas 443 ou 9443. Um shell reverso permite que um operador se conecte ao host comprometido.

A análise também apontou como pistas conexões à infraestrutura associada à campanha e registros codificados de modelos qwen2-tiny- ou ezv- no Xinference. Em separado, a Pluto descreveu MENXIANGYU/qa-whl-1021 como um script que, dentro de um contêiner privilegiado, podia tentar montar discos do host e obter acesso root ao sistema subjacente. Esse comportamento foi atribuído àquele script, não à campanha inteira.

O que fazer se um host carregou um modelo suspeito

A Pluto Security recomenda investigar o host mesmo quando o carregamento falhou ou o uso da GPU parece normal. A sequência sugerida é:

1. Isole o host para limitar conexões e atividade enquanto a equipe investiga.
2. Preserve evidências de processos, conexões de rede, registros, cache e arquivos de inicialização.
3. Procure os indicadores descritos acima e verifique outros sistemas que possam ter carregado os mesmos repositórios. A ausência de um indicador isolado não descarta comprometimento.
4. Remova o minerador, a persistência e quaisquer backdoors identificados; encerrar apenas o processo de mineração não elimina os outros mecanismos.
5. Troque as credenciais acessíveis ao processo a partir de uma máquina limpa.
6. Reconstrua o host a partir de uma imagem confiável se não for possível estabelecer a integridade do sistema.