Um worm chamado ChainDrop foi identificado em mais de 400 pacotes npm comprometidos e consegue se espalhar ao republicar atualizações maliciosas, segundo a Microsoft. Equipes que instalam dependências JavaScript, mantêm registries internos ou executam scripts de instalação devem tratar o caso como possível exposição de credenciais: congele atualizações não essenciais, preserve os manifestos e revogue tokens usados pelos ambientes afetados.

O risco não está limitado ao computador do desenvolvedor que executou npm install. Um pacote adulterado pode alcançar estações de trabalho, servidores de integração contínua, imagens de contêiner, agentes de publicação e ambientes de produção. Se um script de ciclo de vida tiver acesso a variáveis de ambiente ou ao sistema de arquivos, o impacto pode incluir tokens de registro, chaves de nuvem, credenciais de repositório e segredos de serviços internos.

O que aconteceu

O relatório da Microsoft descreve o ChainDrop como um worm de roubo de credenciais escondido em mais de 400 pacotes npm comprometidos. A característica decisiva é a propagação automática: depois de alcançar um ambiente com permissões de publicação, o malware tenta reutilizar essas credenciais para publicar versões maliciosas de outros pacotes. Isso transforma uma dependência contaminada em um ponto de distribuição para a próxima vítima.

A mecânica muda a prioridade da resposta. Não basta procurar um nome de pacote conhecido ou remover uma versão específica. A equipe precisa reconstruir a origem das dependências, identificar quais máquinas executaram scripts e descobrir se algum token foi usado para publicar, acessar código ou movimentar dados. Uma instalação que terminou sem erro também pode ter executado código malicioso durante a instalação.

O caso é diferente de uma vulnerabilidade tradicional. Não há necessariamente uma correção única para aplicar em todos os sistemas. O controle depende de inventário, pinagem de versões, verificação de integridade, restrição de scripts e rotação de credenciais. A decisão operacional deve ser baseada na cadeia de execução, não apenas no alerta do scanner.

Quem deve agir

O grupo mais exposto reúne organizações que usam npm em pipelines de construção, aplicações Node.js, ferramentas internas, extensões, agentes de automação e projetos que aceitam dependências transitivas. Também entram no escopo equipes que permitem publicação por desenvolvedores, mantêm pacotes privados ou usam runners compartilhados com acesso amplo a segredos.

Desenvolvedores individuais devem verificar projetos locais, mas a prioridade empresarial é o ambiente que combina instalação automática com permissões de publicação ou acesso a credenciais. Um runner de CI que pode ler um token de nuvem e instalar qualquer dependência do manifesto representa uma superfície de ataque maior do que uma estação isolada sem acesso privilegiado.

O GitHub mantém orientações específicas para reduzir ataques contra a cadeia de software e destaca mecanismos de autenticação, tokens com escopo e publicação confiável. Essas medidas não substituem a investigação do incidente, mas ajudam a reduzir a capacidade de um pacote comprometido reutilizar credenciais e alcançar outros projetos.

Resposta imediata

Trate a resposta em duas frentes paralelas: contenção da execução e contenção da identidade. Primeiro, suspenda temporariamente instalações e publicações automatizadas em pipelines que não sejam essenciais. Preserve os arquivos package-lock.json, npm-shrinkwrap.json, caches, logs de execução e imagens produzidas. Não apague o ambiente antes de coletar esses dados, porque o horário da instalação e a versão efetivamente resolvida podem ser essenciais para delimitar o alcance.

Prioridade Ação Objetivo
P1 Revogar e substituir tokens npm, GitHub, nuvem e CI disponíveis nos runners que instalaram dependências suspeitas. Impedir reutilização de credenciais roubadas.
P1 Bloquear versões e pacotes identificados pelo fornecedor ou pelo inventário interno. Parar novas execuções do código adulterado.
P1 Separar runners afetados e preservar discos, logs e caches. Manter evidência e evitar propagação.
P2 Reconstruir a partir de dependências aprovadas, com lockfile verificado e scripts controlados. Retomar entregas sem repetir a exposição.
P2 Auditar publicações, acessos a registries e alterações de repositórios. Detectar persistência ou novos pacotes comprometidos.

A rotação deve começar pelos segredos com maior impacto, não pelos mais fáceis de trocar. Inclua tokens de publicação, tokens de leitura que permitam acesso a pacotes privados, chaves de provedores cloud, credenciais de bancos de dados, tokens de automação e segredos presentes nas variáveis de ambiente do CI. Remova sessões e credenciais persistentes quando a plataforma permitir, e confirme que o token antigo deixou de funcionar.

Como investigar

Comece por uma lista de projetos e jobs que executaram npm durante o período de exposição. Compare o lockfile versionado com a árvore realmente instalada, porque caches e comandos sem instalação limpa podem produzir resultados diferentes. Colete nome, versão, integridade, horário de instalação, executor, endereço de saída e identidade usada pelo processo.

Procure sinais em quatro camadas. No endpoint, verifique processos filhos iniciados por scripts de pacote, alterações inesperadas em arquivos de configuração e conexões para domínios que não fazem parte do projeto. No CI, examine leitura de variáveis, uso de comandos de publicação, downloads adicionais e mudanças no cache. No registry, procure novas versões, alterações de mantenedor, publicações fora da janela normal e tokens empregados por endereços ou agentes desconhecidos. No controle de código, investigue commits, workflows, chaves de implantação e regras de proteção modificadas.

Não confunda a presença de um pacote com comprometimento confirmado. A evidência mais forte combina a versão instalada, a execução em um ambiente com permissão e um indicador de acesso ou publicação. Registre também os casos negativos: projetos que tinham o pacote no manifesto, mas não o instalaram; runners sem segredos; e ambientes que usaram uma versão íntegra com integridade verificada.

Controles para o próximo ciclo

A instalação de dependências deve ocorrer em runners descartáveis, sem acesso desnecessário à rede corporativa. Separe o job de resolução de dependências do job que acessa segredos de implantação. Quando possível, instale com lockfile obrigatório, valide hashes e mantenha um proxy ou registry interno capaz de bloquear versões antes que atinjam o pipeline.

Scripts de ciclo de vida merecem tratamento explícito. Desabilitar scripts indiscriminadamente pode quebrar ferramentas legítimas, mas permitir execução irrestrita em qualquer projeto também amplia o impacto de uma adulteração. A opção defensável é usar uma lista aprovada, revisar mudanças de dependência e executar instalações em ambiente isolado. Dependências novas ou atualizações fora do fluxo normal devem passar por revisão de origem, mantenedor, histórico de publicação e comportamento de instalação.

Reduza ainda a capacidade de propagação. Tokens de publicação devem ser específicos por pacote ou organização, ter validade curta e exigir autenticação multifator resistente a phishing quando disponível. A publicação confiável deve vincular o artefato a um workflow conhecido, com ambiente protegido e aprovação para mudanças sensíveis. Nenhum runner de teste deveria possuir permissão de publicação em produção.

As equipes que já mantêm procedimentos de resposta podem usar o guia interno de resposta a incidentes para organizar papéis, preservação e comunicação. Para a fase de detecção, o material sobre logs de segurança ajuda a estruturar a coleta, mas o caso exige acrescentar registros do registry, do CI e do gerenciador de segredos.

Decisão operacional

Se um pacote suspeito foi instalado em um runner com token de publicação ou acesso cloud, classifique o ambiente como potencialmente comprometido até concluir a rotação e a investigação. Se o pacote apenas apareceu em um lockfile não executado, registre a ocorrência, bloqueie a versão e faça uma nova resolução controlada. Se houver publicação desconhecida, alteração de workflow ou uso anômalo de credencial, escale para resposta a incidente e considere todos os artefatos publicados pelo mesmo proprietário como parte do escopo.

A retomada deve acontecer por etapas: primeiro projetos sem exposição de segredos; depois pipelines reconstruídos em runners limpos; por fim ambientes que dependem de pacotes privados ou possuem publicação automatizada. Libere cada etapa somente após confirmar versões aprovadas, integridade dos artefatos, credenciais substituídas e ausência de atividade suspeita nos logs.

O ChainDrop mostra por que a segurança de dependências não pode terminar no scanner de vulnerabilidades. A defesa precisa controlar quem pode publicar, onde o código é instalado, quais scripts executam e que segredos ficam disponíveis nesse momento. Para a maioria das empresas, a ação mais urgente hoje é revogar credenciais expostas e reconstruir os pipelines críticos com dependências verificadas.

Fontes

Microsoft Security Blog, relatório sobre o ChainDrop, publicado em 2026-08-04.

GitHub Security — Supply Chain Security, orientações e atualizações sobre ataques à cadeia de software.