Conter a propagação de worms no npm entre máquinas de desenvolvedores e contas de publicação

O que é

Situação em 25 de outubro de 2026. Este padrão de contenção usa o relatório da Microsoft sobre ChainDrop, de 4 de agosto de 2026, e o aviso dos mantenedores do Tensorlake, publicado em 8 de outubro de 2026, nas versões consultadas para esta análise. Consulte ambos novamente para verificar revisões nas listas de pacotes, nos indicadores de persistência e nas instruções de recuperação; a quantidade de pacotes é uma observação do relatório, não um inventário atual completo.

A Microsoft relata mais de 400 pacotes npm afetados. Código executado durante a instalação roubava credenciais e usava o acesso de publicação para se propagar para outros pacotes. Separadamente, o Tensorlake confirma a versão npm não autorizada 0.5.144, incluindo os pacotes nativos enumerados no aviso. Sua versão de referência para recuperação é a 0.5.143; trata-se de uma reversão, não de uma nova versão corrigida.

Por que importa

A Microsoft descreve uma exposição que vai das máquinas de desenvolvedores às credenciais de CI, aos repositórios e aos artefatos produzidos por builds afetados. Assim, quem consome uma dependência e tem permissão de publicação pode acabar se tornando um distribuidor. O alcance do incidente corresponde ao conjunto de identidades e recursos acessíveis a partir do ambiente de instalação, não apenas à aplicação que solicitou a dependência.

Um build bem-sucedido não permite concluir se uma publicação foi autorizada. Os revisores precisam de evidências que conectem o artefato do pacote, a revisão do código-fonte, o workflow e a aprovação do lançamento. Trate alterações inesperadas em qualquer um desses elementos como motivo para investigar.

Como aplicar

• Suspenda os jobs de instalação e publicação afetados. Faça um inventário das versões exatas em arquivos de lock, registros do registro de pacotes, caches e logs de build, incluindo dependências transitivas. Registre quais estações de trabalho, runners e artefatos derivados as utilizaram. Preserve as evidências antes de substituir os ambientes.
• Em um runner limpo, com um arquivo de lock revisado, use npm ci --ignore-scripts. A documentação do npm define ci como uma instalação baseada no arquivo de lock e ignore-scripts como a supressão dos scripts dos pacotes. Verifique o build resultante antes de adotar essa política: dependências que exigem scripts de instalação podem precisar de um tratamento revisado individualmente.
• Remova as credenciais de publicação dos jobs de instalação de dependências. Quando pacotes privados exigirem autenticação, use tokens granulares somente para leitura. Migre os workflows de publicação compatíveis para publicação confiável, teste a transição e depois revogue os tokens de escrita obsoletos e restrinja a publicação com tokens tradicionais. O npm permite exigir autenticação de dois fatores e, ao mesmo tempo, proibir esses tokens; a publicação via OIDC continua disponível.
• Compare as versões publicadas no registro com os registros de lançamento aprovados. Revise arquivos de workflow, branches do repositório e alterações de configuração das ferramentas de desenvolvimento que sejam inesperados. Investigue diferenças sem explicação mesmo quando o pacote publicado tiver proveniência ou não houver um commit correspondente no código-fonte.
• Se a versão maliciosa do Tensorlake foi executada, siga a precaução contra persistência antes de revogar credenciais: desative o componente gh-token-monitor pelo procedimento específico para a plataforma descrito no aviso. Ele pode destruir dados do usuário quando o token do GitHub monitorado é revogado. Faça a rotação das credenciais a partir de uma máquina limpa e recrie os sistemas afetados.

Armadilhas

ignore-scripts não neutraliza código malicioso executado em tempo de execução. Comandos explícitos como npm run continuam executando o script solicitado. A autenticação de dois fatores não revoga tokens roubados, e restaurar uma dependência limpa não desfaz publicações não autorizadas. Confirme o acesso às contas, o estado dos repositórios e os componentes usados nos novos builds antes de reabrir a publicação.