Como o vazamento do código do worm Shai‑Hulud gerou uma avalanche de malwares no npm

O ecossistema de software open source — especialmente registries de pacotes como o npm, usado no desenvolvimento JavaScript — depende fortemente de confiança. Desenvolvedores instalam milhares de dependências mantidas por pessoas que muitas vezes nunca conheceram. O caso do Shai‑Hulud mostrou como essa confiança pode ser explorada em larga escala.

Em maio de 2026, o grupo de cibercrime TeamPCP publicou o código‑fonte do worm Shai‑Hulud e incentivou outras pessoas a utilizá‑lo. Pouco depois, novos pacotes maliciosos começaram a aparecer no npm — alguns deles clones diretos do malware original. O resultado foi uma rápida multiplicação de ataques à cadeia de suprimentos de software.

Quando um ataque vira “kit” reutilizável

Antes mesmo da divulgação do código, o Shai‑Hulud já havia sido usado em uma série de ataques contra ecossistemas open source como npm e PyPI. Mas a situação mudou de patamar quando o código atribuído ao worm apareceu publicamente em repositórios no GitHub em maio de 2026, acompanhado de instruções sobre como executar o framework. Pesquisadores de segurança alertaram que a publicação funcionava como um manual para novos ataques à cadeia de suprimentos.

Na prática, isso reduz drasticamente a barreira de entrada. Em vez de desenvolver malware do zero ou analisar campanhas existentes, outros atacantes podem simplesmente reutilizar o código e adaptá‑lo para novos alvos.

Poucos dias depois da divulgação, pesquisadores já estavam observando uploads suspeitos no npm que imitavam ou reutilizavam o comportamento do Shai‑Hulud.

O concurso hacker que “gamificou” os ataques

A situação ficou ainda mais preocupante quando o TeamPCP, junto com operadores do fórum hacker BreachForums, promoveu um concurso oferecendo cerca de US$1.000 em Monero para quem conseguisse comprometer o maior número de pacotes open source usando o Shai‑Hulud.

Os participantes eram avaliados pelo impacto do ataque — por exemplo, pelo número de downloads dos pacotes comprometidos. Isso cria um incentivo claro para atacar bibliotecas populares ou cadeias de dependências grandes, aumentando o alcance do malware.

Pesquisadores descreveram o modelo como uma forma de “gamificação” de ataques à cadeia de suprimentos, incentivando vários atores independentes a executar campanhas simultaneamente usando o mesmo kit de ataque.

Clones do malware aparecem rapidamente no npm

Quase imediatamente após a divulgação do código, pesquisadores detectaram novos pacotes maliciosos enviados ao npm por atores imitadores. Uma investigação identificou quatro exemplos:

• chalk-tempalte
• @deadcode09284814/axios-util
• axois-utils
• color-style-utils

Pelo menos um deles continha um clone não ofuscado do Shai‑Hulud, enquanto outros incluíam ladrões de credenciais ou funcionalidades de botnet.

A velocidade com que esses pacotes apareceram mostra como um malware open source pode se espalhar rapidamente quando a infraestrutura do ataque se torna pública.

Typosquatting: o truque por trás de nomes como “chalk-tempalte”

Grande parte desses pacotes utiliza uma técnica comum chamada typosquatting.

O método consiste em publicar pacotes com nomes quase idênticos aos de bibliotecas legítimas. A ideia é que desenvolvedores instalem o pacote errado por engano — ou que o erro passe despercebido em atualizações automáticas de dependências.

Alguns exemplos:

• chalk-tempalte, que imita o padrão do pacote legítimo chalk-template
• axois-utils, que lembra bibliotecas relacionadas ao popular cliente HTTP axios

Como muitas instalações do npm acontecem automaticamente em pipelines de build ou em cadeias de dependências, um único pacote malicioso pode executar código durante a instalação e comprometer o ambiente de desenvolvimento.

O que o malware Shai‑Hulud é capaz de fazer

O Shai‑Hulud não é apenas um pacote malicioso comum. Ele se comporta como um worm de cadeia de suprimentos que se propaga sozinho.

Análises de pesquisadores indicam que o malware pode:

• Roubar credenciais de ambientes de desenvolvimento e runners de CI/CD
• Coletar tokens e segredos de nuvem de serviços como AWS, GCP e Azure
• Exfiltrar dados sensíveis para repositórios controlados pelos atacantes
• Inserir backdoors em outros pacotes caso encontre tokens de publicação de mantenedores

Em incidentes anteriores, o worm conseguia publicar automaticamente versões comprometidas de qualquer pacote ao qual tivesse acesso via token roubado — permitindo que o ataque se espalhasse pelo ecossistema npm sem um servidor central de comando.

Por que especialistas veem isso como uma grande escalada

O Shai‑Hulud já era preocupante por seu comportamento semelhante a um worm e por focar diretamente na infraestrutura usada por desenvolvedores.

Mas dois fatores elevaram o risco para outro nível:

1. Código do ataque disponibilizado publicamente

Ao liberar o código‑fonte, os criadores transformaram o malware de uma campanha específica em uma ferramenta reutilizável por qualquer ator malicioso.

2. Incentivos financeiros e competição

O concurso promovido em fóruns hackers criou um incentivo direto para experimentar e lançar novos ataques.

Juntos, esses elementos mudam o modelo de ameaça: em vez de um único grupo operando o malware, agora múltiplos atores podem lançar ataques simultaneamente usando a mesma base de código.

O alerta para o ecossistema open source

O caso Shai‑Hulud evidencia uma tendência crescente: atacantes estão mirando a infraestrutura de desenvolvimento de software — registries de pacotes, pipelines CI/CD, fluxos de release e credenciais de mantenedores.

Quando um pacote malicioso entra nesse ecossistema, ele pode executar código na instalação, extrair segredos de sistemas de build e potencialmente comprometer todos os projetos que dependem daquela biblioteca.

A rápida aparição de clones do malware após a divulgação do código mostra como um único ataque à cadeia de suprimentos pode escalar rapidamente quando as ferramentas do ataque se tornam públicas.

Para equipes de segurança e desenvolvedores, a lição é clara: proteger aplicações não basta. É preciso proteger também toda a cadeia de ferramentas e dependências usada para construí‑las.