Guias de Segurança
Worms na cadeia de suprimentos do npm: como as credenciais são roubadas na instalação e como se defender
O ChainDrop envenenou 444 pacotes npm em menos de quatro horas em agosto de 2026 — e os publicou com proveniência válida. Ele coleta credenciais no momento da instalação e depois usa o token do GitHub roubado para copiar seus repositórios privados para repositórios públicos. O que de fato o detém.
Para quem é este texto: quem desenvolve com npm ou pnpm, guarda código no GitHub ou faz deploy a partir de CI. Ele se baseia em pesquisas públicas de fornecedores e laboratórios e não contém passos de exploração nem amostras.
O que aconteceu (ChainDrop, agosto de 2026)
4 ago. 2026
A conta do GitHub de um mantenedor de pacotes de cache muito usados foi comprometida. O atacante acionou os workflows de release do GitHub Actions já existentes nos projetos para publicar versões envenenadas no npm.Em quatro horas
444 pacotes e 2.212 versões foram envenenados, incluindo pacotes cujos downloads semanais somados passam de 500 milhões.Na instalação
Hooks de instalação coletaram credenciais de npm, GitHub, nuvem (AWS/GCP/Azure), chaves SSH, Kubernetes e CI/CD — incluindo, segundo análises publicadas, tokens OIDC de vida curta extraídos da memória dos runners de CI.Depois
As credenciais roubadas foram usadas para republicar todos os pacotes que a vítima podia publicar — autopropagação —, e os segredos coletados foram exfiltrados para repositórios públicos do GitHub criados pelo atacante.
O principal dano desta família: seus repositórios privados viram públicos
Worms da família Shai-Hulud usam o token do GitHub roubado para copiar os repositórios privados da vítima para repositórios públicos — foram relatados nomes terminados em -migration. O GitHub não foi invadido. Um token tirado do seu notebook ou do seu runner de CI faz isso como uma ação legítima, com os seus próprios privilégios. Por isso "esperar a plataforma corrigir" não é uma defesa aqui.
Por que não foi detido
Adicionar uma dependência / instalar no CI
↓ preinstall / postinstall roda automaticamente
Código arbitrário na sua máquina ou runner
↓ segredos de npm / GitHub / nuvem / SSH / CI coletados
Ações legítimas com tokens roubados
repositórios privados copiados como públicos / pacotes republicados para se espalhar
O que não ajudou
- Assinaturas e proveniência — emitidas legitimamente com os privilégios do mantenedor, então a verificação passou
- "É um pacote grande e popular" — os envenenados eram justamente assim
- Fixar a versão, sozinho — você ainda o baixa numa instalação limpa ou na próxima atualização
- Esperar uma correção da plataforma — o que foi usado eram tokens válidos e APIs públicas
O que ajuda
- Scripts de instalação desativados por padrão — o código nunca roda
- Um período de espera antes de adotar versões — evita o intervalo entre a publicação e a remoção
- Tokens de vida curta e escopo restrito — limita o que um token roubado pode fazer e por quanto tempo
- Restrições de saída de rede nos runners de CI — fecha o caminho de exfiltração
Cinco coisas para fazer hoje
Procure no seu próprio lockfile
Verifique se há alguma versão relatada como envenenada (por exemplo keyv@6.0.0, flat-cache@6.1.24, file-entry-cache@11.1.6). Um resultado limpo é uma boa notícia, mas os passos 2 em diante preparam você para o próximo ataque parecido, então continue.
Desative os scripts de instalação por padrão
Faça o CI usar npm ci --ignore-scripts; no pnpm, defina ignore-scripts=true no .npmrc e libere explicitamente só as dependências que realmente precisam compilar. Esta é a mudança de maior valor, porque remove a etapa de execução da qual este ataque depende.
Espere alguns dias depois de uma versão sair antes de adotá-la
Não pegue uma versão no momento em que ela chega — um período de espera de 3 a 7 dias basta. Quando o tempo entre a publicação e a remoção é de horas a dias, como aqui, só esperar já evita o problema. Se você usa PRs de atualização automática, coloque esse atraso na configuração.
Adicionado em 2026-09-05: isso não precisa mais depender de disciplina. O guia oficial de segurança do Node.js lista, entre as mitigações de cadeia de suprimentos, definir um período de espera para dependências com --min-release-age (npm v11.10.0+) para não instalar pacotes publicados recentemente. Se puder ser configuração em vez de disciplina, faça virar configuração. Um procedimento que depende de alguém lembrar costuma ser pulado num dia corrido.
Faça o inventário dos seus tokens; reduza vida útil e escopo
Troque os personal access tokens clássicos do GitHub pelos fine-grained (de granularidade fina), encurte a validade e limite-os aos repositórios que precisam deles. Não deixe tokens de publicação do npm parados no CI. O cuidado com chaves e segredos está em o que é perigoso em .env e chaves de API e privilégio mínimo para chaves SSH. O objetivo é que um token roubado consiga causar pouco dano.
Audite a sua própria conta do GitHub
Procure repositórios públicos que você não criou (nomes terminados em -migration, descrições estranhas), workflows do GitHub Actions que você não adicionou, configurações executáveis deixadas em .vscode/tasks.json ou .claude/, e chaves de API ou chaves SSH que você não reconhece. Para monitorar automaticamente vulnerabilidades conhecidas nas suas dependências, veja primeiros passos com o osv-scanner.
Se suspeitar de infecção, acerte a ordem
Os pesquisadores destacam um ponto que vale repetir: remova qualquer componente residente deixado na máquina (scripts que vigiam tokens e afins) ANTES de revogar os tokens. Se inverter a ordem, o componente residente pode reagir à revogação. Em linhas gerais:
1. Desconecte da rede
2. Remova a persistência e os arquivos suspeitos
3. Revogue e reemita na ordem npm → GitHub → nuvem → SSH → Kubernetes
4. Apague node_modules e os caches e reinstale do zero
5. Revise seus repositórios públicos e o histórico de publicação de pacotes
Se você não tem logs, a resposta é "desconhecido", não "limpo". Siga como se tivesse sido comprometido.
A visão deste site: uma assinatura atesta a origem, não a segurança
Assinatura e proveniência são há anos a principal recomendação para a cadeia de suprimentos — e esta campanha passou por elas. Isso não surpreende: uma assinatura diz quem publicou algo, não se o conteúdo é seguro. Uma assinatura válida de uma conta comprometida é válida e perigosa ao mesmo tempo. Por isso tratamos a proveniência não como um controle que deixa você seguro, mas como uma ferramenta forense para medir o alcance do impacto depois de um incidente. A prevenção depende de duas outras coisas: não executar código de terceiros na instalação e não deixar segredos onde esse código roda.
Fontes
- Unit 42 (Palo Alto Networks) — ChainDrop: Inside a Self-Propagating npm Worm (propagação, credenciais coletadas, indicadores)
- StepSecurity — ChainDrop npm Worm (indicadores de detecção e ordem de remediação)
- Elastic Security Labs — CHAINDROP worm hits 400+ npm packages
- Node.js, "Security Best Practices" — nodejs.org (vetores de ataque à cadeia de suprimentos e mitigações:
--ignore-scripts, lockfiles,npm cie o período de espera--min-release-age; consultado em 5 de setembro de 2026) - SecurityWeek — Over 400 NPM Packages Infected in ChainDrop Supply Chain Attack (escala e sequência)
- Wiz — Shai-Hulud npm Supply Chain Attack (a técnica de copiar repositórios privados para públicos)
Leia a seguir
- Um caso de 2026: a cadeia TanStack, Nx Console e GitHub — o que os desenvolvedores devem verificar
- Prática: monitore automaticamente CVEs de dependências com o osv-scanner / barre segredos no commit com o gitleaks
- Fundamentos: o que é perigoso em .env e chaves de API / privilégio mínimo para chaves SSH
- Comparação: Git auto-hospedado ou GitHub, qual é mais seguro
- Falhas que chegam pelas dependências: prototype pollution no Node.js (conta mesmo que o merge tenha sido escrito por uma dependência)
- Termos: o que é malware
- O padrão: as violações de 2026 entraram por credenciais válidas (o mesmo formato — um token roubado executando ações comuns)
FAQ
QComo rodar npm install pode roubar minhas credenciais?
Porque os pacotes podem trazer scripts que rodam automaticamente na instalação (preinstall / postinstall). Adicionar uma dependência equivale, portanto, a deixar esse código ser executado com os seus privilégios. O ChainDrop usou exatamente isso para coletar credenciais de npm, GitHub, nuvem, SSH e CI/CD.
QO que significa repositórios privados serem publicados?
Worms desta família usam o token do GitHub roubado para copiar os repositórios privados da vítima para repositórios públicos — foram relatados nomes terminados em -migration. O GitHub em si não foi invadido: um token tirado da sua máquina ou do seu CI executa a ação com os seus próprios privilégios. É por isso que esperar uma correção do lado da plataforma não protege você.
QPacotes assinados e com proveniência não são seguros?
Foi exatamente isso que foi contornado aqui. O atacante usou os privilégios do mantenedor para acionar o workflow de release já existente do projeto, então as versões envenenadas saíram com proveniência válida. Uma assinatura atesta quem publicou algo, não se o conteúdo é seguro. Uma assinatura válida de uma conta comprometida continua sendo uma assinatura válida.
QQual é a medida mais eficaz para fazer hoje?
Duas coisas: desativar os scripts de instalação por padrão (npm ci --ignore-scripts, ou ignore-scripts=true no pnpm) e parar de adotar versões recém-lançadas na hora — espere alguns dias. A primeira impede que o código rode; a segunda evita o período mais perigoso, as horas ou dias entre a publicação e a remoção.