Como o ataque Shai-Hulud comprometeu o ecossistema npm

Como o ataque começou

Por volta das 9h UTC de 4 de agosto de 2026, um invasor assumiu o controle da conta de Jared Wray no GitHub . Com esse acesso, alterou diretamente a branch main do repositório keyv e publicou novas versões maliciosas em toda a família de pacotes keyv e cacheable .

A primeira leva atingiu 11 pacotes nos dois namespaces, incluindo keyv, cacheable-request, cache-manager, @cacheable/utils, flat-cache e file-entry-cache . Pesquisadores da Aikido Security, StepSecurity — que acompanha a ameaça com o nome ChainDrop —, Socket e Chainguard confirmaram o comprometimento nas primeiras horas .

O que foi inserido nos pacotes

Cada pacote contaminado recebeu o mesmo padrão de infecção: dois arquivos novos, setup.mjs e Math_Symbol.js, além de uma alteração no package.json que adicionava o script:

"preinstall": "node setup.mjs"

Esse tipo de script é executado automaticamente durante a instalação. Assim, quando um desenvolvedor ou sistema de integração contínua (CI) rodava npm install, o setup.mjs era acionado antes que o processo terminasse .

O arquivo funcionava como um dropper — um carregador cuja função era baixar um binário legítimo do runtime JavaScript Bun a partir do GitHub Releases e usá-lo para executar a segunda etapa, o payload ofuscado Math_Symbol.js, com aproximadamente 710 a 728 KB .

A Microsoft Threat Intelligence confirmou que o código era uma variante do Mini Shai-Hulud . O malware procurava uma ampla variedade de segredos nos ambientes infectados , entre eles:

• tokens de autenticação do npm;
• tokens de acesso pessoal do GitHub (PATs);
• chaves da AWS;
• segredos do Kubernetes;
• tokens do HashiCorp Vault;
• chaves da Stripe;
• tokens do Slack;
• chaves SSH;
• arquivos de estado do Terraform;
• credenciais do Docker;
• configurações de VPN.

Por que o worm se espalhou tão rápido

O aspecto mais perigoso do ataque foi a capacidade de autopropagação. Depois de roubar tokens de publicação do npm e PATs do GitHub no ambiente infectado, o worm usava essas credenciais para publicar versões maliciosas de pacotes pertencentes a outros mantenedores, sem relação direta com a conta inicialmente comprometida .

O número de pacotes afetados cresceu rapidamente:

• em aproximadamente duas horas, a StepSecurity contabilizava 435 pacotes e 1.557 versões contaminados ;
• no início da tarde, pelo horário da Europa Central (CEST), a Aikido Security registrava 868 pacotes comprometidos em 1.381 versões ;
• ao fim do dia, o total já havia ultrapassado 1.280 pacotes e 1.680 versões, segundo o BleepingComputer e outras publicações .

A ameaça também atravessou os limites dos namespaces originais. Em vez de permanecer na família keyv/cacheable, chegou a pacotes associados a organizações como Deliveroo, Ornikar, OneReach, Picsart, Qlik e ServiceTitan, entre outras .

Para onde foram os dados roubados

As credenciais coletadas eram exfiltradas para um repositório do GitHub controlado pelo invasor. O worm podia criar um novo repositório ou usar um espaço dedicado para armazenar os dados roubados .

O payload também incluía vários canais redundantes de exfiltração . Na prática, isso tornava a operação mais resistente à derrubada de um único repositório ou canal de comunicação.

O que fazer se um pacote afetado foi instalado

Os pesquisadores recomendaram tratar qualquer ambiente que tenha executado uma versão contaminada como potencialmente comprometido. A resposta não deve se limitar à exclusão dos arquivos maliciosos: os segredos disponíveis na máquina ou no runner de CI/CD podem ter sido capturados .

1. Fixe ou reverta as dependências

Interrompa a instalação das versões afetadas e fixe cada dependência em uma versão comprovadamente limpa. Também é possível usar os mecanismos de override do npm, Yarn ou pnpm — por exemplo, a propriedade overrides no package.json — para impedir que uma versão contaminada seja reinstalada por engano .

Revise ainda os arquivos de lock, incluindo package-lock.json, yarn.lock e pnpm-lock.yaml. A verificação deve incluir dependências transitivas, que podem ter sido puxadas indiretamente pelo projeto .

2. Considere o host totalmente comprometido

Não basta remover setup.mjs, Math_Symbol.js ou o pacote de node_modules . Qualquer máquina de desenvolvedor, servidor de build ou runner que tenha executado npm install com uma versão afetada deve ser tratada como comprometida.

A recomendação é preservar evidências para investigação e reconstruir o ambiente a partir de uma imagem limpa, quando possível.

3. Revogue e recrie todas as credenciais

Revogue e gere novamente todos os segredos que possam ter estado disponíveis no ambiente infectado . Isso inclui:

• tokens do npm, clássicos e granulares;
• PATs e tokens de acesso refinado do GitHub;
• chaves do AWS IAM e outras chaves de acesso da AWS;
• tokens de contas de serviço do Kubernetes;
• tokens do HashiCorp Vault;
• chaves da Stripe;
• tokens do Slack;
• chaves SSH;
• credenciais do Docker;
• tokens de VPN.

4. Remova os mecanismos de monitoramento antes de trocar os tokens

Esse é um detalhe crítico da resposta. Em alguns casos, o malware configura observadores de workflows do GitHub capazes de capturar novamente um token assim que ele é criado .

Por isso, os pesquisadores recomendaram desativar ou remover primeiro qualquer serviço de monitoramento ou mecanismo de persistência suspeito e só depois fazer a rotação das credenciais .

5. Limpe os caches e reconstrua tudo

Limpe os caches do npm, pnpm e Yarn em máquinas de desenvolvimento e runners de CI/CD. Faça o mesmo com os caches de build do Docker .

Depois, reconstrua os artefatos do zero. Dependências contaminadas podem continuar presentes em caches de compilação, camadas de imagens Docker ou artefatos previamente gerados .

6. Audite o GitHub e os ambientes de CI/CD

Procure repositórios recém-criados, workflows não autorizados e commits suspeitos . Também vale verificar artefatos de persistência que possam ter sido deixados pelo worm, como .claude/settings.json e .vscode/tasks.json .

A auditoria deve abranger contas de desenvolvedores, organizações do GitHub, tokens, aplicativos OAuth, Actions e runners auto-hospedados.

O que o caso revela sobre a segurança do npm

O ataque de 4 de agosto mostrou como uma única conta de mantenedor pode se transformar em um ponto de entrada para uma crise muito maior. O invasor não precisava ter acesso direto a todos os pacotes atingidos: bastava roubar tokens com permissão de publicação e deixar que o próprio worm ampliasse o alcance da campanha.

O uso de um binário legítimo do Bun para executar o payload, a autopropagação por meio de credenciais roubadas e os canais redundantes de exfiltração tornaram a operação mais sofisticada do que ataques anteriores de cadeia de suprimentos .

Para as equipes de engenharia e segurança, as principais lições são claras: fixar versões de dependências, revisar árvores de dependência, desativar scripts preinstall e postinstall quando isso for viável, monitorar atividades incomuns no GitHub e manter um plano de resposta específico para comprometimentos de dependências de software.