A próxima grande versão do npm, a v12, com lançamento previsto para julho de 2026, deixará de executar scripts de instalação de dependências por padrão.
Estamos aliviados em saber disso. Desativar os scripts de instalação é a mudança mais útil que o npm poderia fazer em suas configurações padrão. A comunidade sofreu uma enxurrada de ataques à Supply chain no último ano, como Nx s1ngularity e Shai-Hulud, que exploraram scripts de pós-instalação. Esta atualização do npm é uma mudança muito aguardada que reduzirá um enorme vetor de ataques à Supply chain.
O que o npm está mudando
Quando você executa npm install hoje, qualquer pacote em qualquer lugar da sua árvore de dependências pode definir scripts de ciclo de vida chamados preinstall, install, ou postinstall, e o npm os executa automaticamente para você. O código é executado no segundo em que você instala, antes de importar qualquer coisa ou executar seu próprio código.
A v12 põe um fim a isso. Os scripts só são executados para pacotes que você colocou em uma lista de permissões (allowlist), que você constrói com `npm approve-scripts`, bloqueia o restante com `npm deny-scripts` e faz commit junto com o restante do seu projeto.
Algumas outras mudanças menores vêm com ele. Dependências Git não são mais resolvidas a menos que você passe --allow-git, o que fecha um caminho de execução mais silencioso onde o npmrc de uma dependência Git poderia sobrescrever o executável Git e executar código mesmo com --ignore-scripts definido. Dependências de URL remoto, como tarballs https, também param de ser resolvidas a menos que você passe --allow-remote, fechando um caminho onde um invasor poderia direcionar uma dependência para uma URL externa que ele controla e trocar o payload a qualquer momento.
A allowlist também abrange código que nunca aparece no campo de scripts. Quando um pacote envia um binding.gyp, o npm executa uma reconstrução implícita do node-gyp para ele durante a instalação, então uma dependência com um package.json impecável pode ainda executar código apenas carregando esse arquivo de build. A v12 trata esse build como um script declarado, então ele será bloqueado a menos que o pacote esteja na sua allowlist. Nossa equipe de pesquisa mapeou recentemente o quão estranho e perigoso é esse potencial caminho de ataque.
Tudo isso já está no npm 11.16.0, com avisos, para que você possa ver o que será afetado antes de fazer o upgrade.
Os exploits de postinstall que a mudança no npm corrige
Quase todos os worms e ladrões de credenciais que atingiram o npm desde o outono passado foram executados durante o tempo de instalação, e não em tempo de execução. O padrão para esses ataques geralmente envolve um invasor primeiro assumindo o controle de um pacote confiável, geralmente por meio de phishing de uma conta npm de um mantenedor ou roubo de um token de publicação. Em seguida, os invasores publicam uma nova versão com um script de postinstall adicionado ao seu package.json, muitas vezes deixando o código-fonte real intocado, para que nada pareça obviamente errado.
Quando alguém executa npm install, o npm executa esse script automaticamente como o usuário. Ele faz o fingerprint da máquina, baixa o payload real de um servidor do invasor, o executa e se autoexclui, enquanto o payload procura por tokens, chaves SSH e outros itens valiosos, e então os envia.
Nesses ataques, você nem precisa usar o pacote malicioso ou importá-lo para se tornar uma vítima. Você só precisa ter o azar de executar npm install enquanto o pacote está infectado.
Com o padrão da v12 em vigor, a instalação simplesmente pararia no pacote malicioso, a menos que esse pacote exato esteja na allowlist que você confirmou. O invasor ainda pode publicar a versão envenenada, mas em uma máquina com a v12, ela permanece como arquivos inertes em node_modules.
Por que isso é importante
A onda de ataques de scripts postinstall começou no outono passado e não parou de verdade. Vimos este ataque a um pacote Red Hat há apenas uma semana. Alguns dos grandes ataques que se aproveitaram disso e tiraram o sono de nossos pesquisadores de segurança incluem:
- Nx s1ngularity, agosto de 2025. Um token de publicação roubado impulsionou versões maliciosas do Nx cujo script de postinstall, telemetry.js, foi executado na instalação. Ele extraiu tokens do GitHub, credenciais do npm, chaves SSH e carteiras de criptomoedas, e então os carregou para repositórios públicos do GitHub. As aproximadamente 2.300 credenciais que ele coletou serviram de base para futuros ataques.
- Shai-Hulud, novembro de 2025. Um worm autorreplicante que atingiu cerca de 500 pacotes em Zapier, ENS, PostHog, Postman e AsyncAPI, instalou o runtime Bun durante a configuração, executou o TruffleHog para extrair Secrets, e os despejou em repositórios públicos do GitHub.
- O sequestro do axios, março de 2026. Uma conta de mantenedor sequestrada enviou uma dependência que existia apenas para executar um hook de postinstall e soltar um RAT multiplataforma. O axios realiza cerca de 100 milhões de downloads por semana.
- Mini Shai-Hulud, maio de 2026. Um worm derivado do OG Shai Hulud, plantando um hook de preinstall que puxou o runtime Bun e executou um ladrão de credenciais. Ele se espalhou por mais de cem pacotes em TanStack, UiPath e Mistral AI e se tornou o primeiro worm npm a publicar malware com proveniência de build válida.
Este não é apenas um problema do npm, embora o npm seja o maior alvo. A mesma ideia aparece em outros ecossistemas, como o Composer do PHP, onde mais de 200 versões do Laravel-Lang foram reescritas em maio para executar automaticamente um ladrão de credenciais via autoloader (o Composer agora possui filtragem nativa de malware impulsionada por Aikido para proteger os usuários downstream).
O que fazer agora
Faça upgrade para o npm 11.16.0 ou posterior, pois todas as três mudanças já estão lá, com avisos. Se você já estiver na versão 11.15.0+, --allow-git está disponível agora, e --allow-remote desde a 11.15.0, então você pode começar a bloqueá-los sem esperar pela v12. Para scripts, execute npm approve-scripts --allow-scripts-pending para ver o que seria bloqueado, aprovar os pacotes em que você confia, e fazer commit do package.json. O que você pular deixará de ser executado quando a v12 for lançada. Verifique isso, pois muitos pacotes legítimos usam scripts de instalação para builds nativos e configuração, e uma vez que o padrão mude, essas instalações precisarão de aprovação.
Você também pode instalar o Safe Chain da Aikido, um wrapper seguro e gratuito para npm, npx e yarn que se integra ao seu fluxo de trabalho atual e verifica cada pacote em busca de malware antes da instalação. Ele impede que você instale malware acidentalmente e impõe um período de espera para novas versões de pacotes, o que evita que um bom número de pacotes comprometidos chegue ao seu dispositivo.
Boas configurações padrão protegem as pessoas que nunca abrem um changelog (que é quase todo mundo, quase o tempo todo, exceto pesquisadores de segurança e os devidamente paranoicos). O npm tornar isso seguro por padrão é a decisão correta. Não deveria ter levado um ano de problemas públicos para acontecer, e não resolverá tudo, mas estamos felizes que esteja aqui.
