NPM sob ataque: o verme que rouba credenciais e coloca em jaque suas pipelines de CI

Em 4 de agosto de 2026 foi detectada uma campanha de envenenamento em npm que começou com a libertação maliciosa [email protected] e expandiu-se rapidamente por múltiplos nomes de pacote e organizações. Tratou-se de um verme projetado para roubar credenciais, que foi ativada através de um programa de pré-instalação e encarregava um binário empacotado capaz de exfiltrar tokens e chaves de repositórios, registros, nuvens e runners de integração contínua (CI), além de incluir mecanismos para publicar novas versões com identidades roubadas.

A telemetria de pesquisadores independentes não concordou em um único conteo definitivo: SafeDep verificou centenas de versões maliciosas em dezenas de pacotes, Aikido apresentou uma contagem ainda maior e outras observações registraram pontos parciais. O número total de pacotes ou versões informadas indica escala, mas não equivale ao número de sistemas vítimas; essa determinação exige verificar a versão exata resolvida em cada máquina e, sobretudo, se o programa de ciclo de vida chegou a ser executado.

Do ponto de vista técnico, a campanha usou um ficheiro pré-install que invocava setup.mjs e colocou um bundle compilado que procurava runtimes como Bun, descarregava componentes e depois executava código que explorava memória do runner, leia segredos em arquivos e variáveis de ambiente, e colocava um "watcher" cuja função era observar revogações de Tokens. Esse watcher coloca um risco operacional importante: rodar primeiro as credenciais pode disparar um controlador local fornecido pelo atacante, portanto, as equipes de resposta devem neutralizar o malware antes de começar a rotação.

A superfície de ataque foi maior porque o repositório comprometido também continha hooks para editores e ambientes de desenvolvimento: arquivos de configuração do Claude Code e do Visual Studio Code que, se confiarem, podem executar setup.mjs ao abrir o projeto. Em ambientes de desenvolvimento e em runners de CI existem dois vectores independentes - o instalador de npm e a configuração do workspace - e ambos devem ser considerados potencialmente perigosos.

A campanha deixou em evidência que as garantias de proveniência e assinatura de build não são uma panaceia: várias das releases envenenadas levaram assinaturas válidas e atestações SLSA porque o fluxo de publicação passou pelo pipeline legítimo do projeto. Uma atestação que verifica o processo de construção não garante por si só que o código fonte que entrou nesse processo seja inocuo, e por isso a verificação da cadeia de fornecimento deve incluir controles sobre o repositório fonte e sobre quem controlou as credenciais de publicação.

Para detectar exposição no seu ambiente, é imprescindível recorrer às fontes locais: inspeccione package-lock.json, npm-shrinkwrap.json, earn.lock e pnpm-lock.yaml para localizar as versões exactas resolvidas; verifique se, nesses pacotes, o manifest continha um programa pré-install ou arquivos suspeitos (por exemplo, setup.mjs ou nomes invulgares incluídos na publicação); e analise logs de CI e de instalação para ver se foram executados programas de ciclo de vida. Não confie em listas públicas de pacotes "latest" ou em bloqueios por nome de espaço; a verificação deve ser por nome exato e versão.

A resposta técnica imediata deve combinar isolamento e eliminação do malware com um plano coordenado de rotação de credenciais. Primeiro, coloque em quarentena máquinas e runners suspeitos e procure e remova o watcher ou qualquer artefato persistente que possa reagir à revogação. Abaixo, rote chaves, tokens e certificados comprometidos. Se rodar sem antes neutralizar o watcher, existe o risco de activar o código do atacante que aproveite a rotação. Finalmente, reconstruia artefatos e contentores desde fontes de confiança e desde árvores de código verificados.

Em infra-estruturas CI/CD e em políticas de desenvolvimento, há medidas concretas para reduzir a exposição futura: atualizar clientes npm que bloqueem programas de ciclo de vida por defeito quando compatível com seu fluxo, desactivar a execução automática de tarefas de workspace em VS Code e Claude Code, adotar tokens efêmeros e OIDC para implantaçãos, restringir permissões de publicação nos registros e exigir autenticação multifator e revisões humanas para liberações críticas. A segurança efetiva combina ferramentas (por exemplo, bloqueio de lifecycle scripts), políticas (princípio de privilégio mínimo) e processos (revisão de commits e controle de acesso a credenciais).

Os equipamentos de manutenção de pacotes devem auditar a sua árvore de trabalho e a história de commits procurando mudanças que tenham propagado arquivos suspeitos a múltiplos subpasquetes. Preste atenção a commits assinados ou verificados por bots que, embora mostrem uma insígnia de verificação, não identificam quem controlou a credencial que assinou a ação. A verificação da assinatura é necessária mas não suficiente; combine esse sinal com controles sobre quem tinha acesso à pipeline e com revisões da integridade do código fonte.

Para consumidores e organizações, a recomendação prática imediata é identificar instâncias concretas que puderam instalar versões afectadas e determinar se foram executados programas de instalação. Se confirmar a execução, isole a máquina e o runner, preserve evidências e proceda a limpeza e rotação de segredos conforme o comando descrito. Se não tiver a certeza do estado de execução, tente as máquinas potencialmente expostas até demonstrar o contrário com imagens ou rebuilds de fontes limpas.

Para aprofundar as práticas de verificação de assinaturas e no quadro SLSA recomendado para atestações da cadeia de fornecimento, consulte a documentação oficial do GitHub sobre verificação de assinaturas About commit signature verification e princípios do projeto SLSA em slsa.dev. Para análise de campanhas e compromissos de repositórios, recursos como o blog de Semgrep coletam exemplos úteis e regras que podem ser aplicadas em digitalização de repositórios; veja sua página de publicações em Semgrep Blog.

Este incidente sublinha uma lição-chave: As defesas da cadeia de abastecimento devem ser proativas, centradas na precisão (versões resolvidas e lockfiles) e na higiene de credenciais. As organizações devem rever seus processos de publicação, endurecer pipelines, limitar o blast radius de tokens e preparar playbooks de resposta que contemplem a campanha de rotatividade ordenada de segredos após a remoção de qualquer mecanismo de vigilância instalado pelo atacante.