A Microsoft Threat Intelligence revelou detalhes de um amplo ataque à cadeia de suprimentos do npm que afetou mais de 400 pacotes associados a publicadores aparentemente não relacionados, incluindo pacotes de ecossistemas de software corporativo como keyv, flat-cache e cache-manager. As versões maliciosas continham uma variante do worm Mini Shai-Hulud, uma carga JavaScript baseada em Bun e altamente ofuscada, projetada para roubar credenciais e se propagar automaticamente republicando atualizações maliciosas.
O ataque é especialmente relevante pela forma como opera: o malware não se limita a roubar tokens de um dispositivo de desenvolvedor ou ambiente de build, mas explora esses tokens para acessar npm, GitHub, Amazon Web Services, Kubernetes e HashiCorp Vault e, então, examina os recursos e segredos permitidos pelas identidades roubadas. De acordo com a análise da Microsoft publicada em 4 de agosto de 2026, qualquer estação de trabalho ou agente de build que tenha importado um pacote afetado, com scripts de ciclo de vida do npm ativados, deve ser considerado potencialmente comprometido.
Execução antecipada em ambientes de desenvolvimento
As versões afetadas geralmente incluíam um script preinstall que executava um arquivo chamado setup.mjs antes da conclusão da instalação do pacote. O arquivo inicia um grande pacote Bun ofuscado, permitindo a execução da carga nos dispositivos dos desenvolvedores e nos nós de build antes do início dos testes da aplicação ou de algumas verificações de segurança tradicionais chegarem a essa etapa.
O worm primeiro examina o ambiente para determinar se está sendo executado em uma estação de trabalho de desenvolvedor ou em uma tarefa de CI/CD. Nos dispositivos de desenvolvedores, ele se dissocia para continuar a execução em segundo plano após o término da instalação, enquanto permanece associado à tarefa em ambientes de CI/CD para explorar segredos do fluxo de trabalho, credenciais do agente e permissões de publicação via OpenID Connect. Ele também verifica se outra instância está em execução e interrompe sua atividade em sistemas com idioma russo, conforme observado pela Microsoft.
Roubo de credenciais e transformação em propagação
A carga começa coletando o que estiver disponível localmente em arquivos de credenciais, variáveis de ambiente, histórico de comandos, chaves SSH e ferramentas de nuvem, além de dados da memória de agentes do GitHub Actions. Entre outras ações, tenta obter um token do GitHub CLI. Em seguida, usa as credenciais extraídas para chamar as APIs de serviços do npm, GitHub, AWS, Kubernetes e HashiCorp Vault, verificar permissões e coletar segredos adicionais.
Os resultados são criptografados em formato JSON compactado usando AES-256-GCM, com a chave AES criptografada por RSA-OAEP-SHA256, e depois enviados a um endpoint HTTPS controlado pelo invasor. O GitHub é usado como canal alternativo de exfiltração quando o canal principal não está disponível. A Microsoft observou que a infraestrutura ativa no momento da análise resolvia para o domínio npm-cache[.]com, enquanto candidatos anteriores incluíam pypi-get[.]com e js-mirror[.]com.
O principal mecanismo de propagação examina os tokens do npm para verificar se eles permitem escrever em pacotes ou contornar a autenticação de dois fatores e, em seguida, baixa o arquivo tarball mais recente de cada pacote disponível para a identidade comprometida. O worm copia a si próprio para o arquivo, adiciona o carregador de configuração e o script de ciclo de vida, incrementa o número da versão de correção e republica o pacote. Isso explica o surgimento de versões maliciosas que parecem atualizações patch comuns, sem commit, pull request ou tag de versão correspondente no repositório de origem.
Caminhos adicionais pelo GitHub
A carga verifica os escopos dos tokens do GitHub, enumera os repositórios que permitem escrita e procura repositórios nos quais as execuções de fluxos de trabalho possam revelar outros segredos. Ela também inclui um caminho direcionado a pacotes npm publicados por meio do GitHub Actions como publicadores confiáveis, o que pode conferir às versões publicadas uma provenance válida, já que a publicação ocorre a partir de uma identidade legítima de fluxo de trabalho.
O worm também pode injetar arquivos de configuração em branches dos repositórios, incluindo caminhos associados ao Claude e ao Visual Studio Code, como .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json e .vscode/setup.mjs. Essas alterações fornecem um caminho secundário de infecção que pode reexecutar a carga durante o uso do Claude ou do Visual Studio Code, mesmo após o término da instalação do pacote original. A Microsoft informou que um dos caminhos de reserva do GitHub também tenta instalar um componente para monitorar tokens, com um manipulador destrutivo condicional quando o token monitorado é revogado.
O que a Microsoft recomenda?
A Microsoft recomenda atualizar o npm CLI para a versão 12 e usar o recurso min-release-age, além de revisar árvores de dependências, arquivos de bloqueio, repositórios de artefatos e caches de CI em busca das cinco versões afetadas, incluindo referências indiretas. Também é necessário fixar versões conhecidamente seguras e limpar os caches do npm e do yarn nos dispositivos dos desenvolvedores e nos hosts de build, especialmente quando os arquivos comprometidos tiverem entrado em um cache de CI compartilhado.
Se um sistema de build ou uma estação de trabalho tiver importado uma versão afetada, as credenciais e os segredos devem ser rotacionados a partir de um dispositivo limpo, pois a execução da segunda etapa pode expor tokens e afetar a integridade do processo de build. As recomendações também incluem ativar a proteção em nuvem do Microsoft Defender Antivirus, as medições do Microsoft Defender for Endpoint e do Microsoft Defender for Containers e o fluxo de investigação do Microsoft Defender XDR nos ativos de desenvolvimento e de CI.
A resposta não deve se limitar à verificação dos dispositivos. As organizações que produzem artefatos de software devem revisar o fortalecimento do processo de lançamento, os escopos dos tokens, as aprovações de fluxos de trabalho, os ambientes protegidos, a proveniência das versões e os mecanismos de detecção de publicações automatizadas incomuns, pois o incidente é consistente com o abuso de pipelines de CI/CD por meio das permissões do GitHub Actions OIDC. Após a remediação, os projetos devem ser reconstruídos a partir de uma linha de base confiável, deve-se confirmar a ausência de indicadores comprometidos nos caches e repositórios de artefatos e revisar as medições em busca de vestígios do Node.js, como Math_Symbol.js, Math_init.js ou arquivos com nomes semelhantes a math_<guid>.js, além de reconstruir as imagens básicas e os agentes de build modulares.