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 predefinição.
Ficamos aliviados ao saber disso. Desativar os scripts de instalação é a alteração mais útil que o npm poderia introduzir nas suas configurações padrão. A comunidade sofreu uma enxurrada de ataques à Supply chain último ano, como o Nx s1ngularity e o Shai-Hulud, que exploravam scripts pós-instalação. Esta atualização do npm é uma mudança há muito esperada que irá reduzir significativamente um importante vetor de ataque à cadeia de abastecimento.
O que o npm está a mudar
Quando executa npm install Hoje em dia, qualquer pacote em qualquer parte da sua árvore de dependências pode definir scripts de ciclo de vida chamados preinstall, instalar, ou postinstall, e o npm executa-os automaticamente por si. O código é executado assim que o instala, antes de importar qualquer coisa ou de executar o seu próprio código.
A v12 põe fim a isso. Os scripts só são executados para os pacotes que tiver incluído numa lista de permissões, que cria com o comando `npm approve-scripts`; bloqueia os restantes com o comando `npm deny-scripts` e submete-os juntamente com o resto do seu projeto.
Vêm incluídas algumas outras alterações menores. As dependências do Git já não são resolvidas, a menos que se passe --allow-git, o que elimina uma via de execução menos visível em que o ficheiro npmrc de uma dependência do Git poderia substituir o executável do Git e executar código mesmo com --ignore-scripts definido. As dependências de URLs remotas, como arquivos tar em https, também deixam de ser resolvidas, a menos que se passe --permitir-remoto, bloqueando uma vulnerabilidade que permitiria a um atacante direcionar uma dependência para um URL externo sob o seu controlo e substituir a carga útil a qualquer momento.
A lista de permissões também abrange código que nunca aparece no campo «scripts». Quando um pacote inclui um ficheiro «binding.gyp», o npm executa uma reconstrução implícita do «node-gyp» durante a instalação; assim, uma dependência com um «package.json» impecável pode ainda assim executar código apenas por conter esse único ficheiro de compilação. A v12 trata essa compilação como um script declarado, pelo que será bloqueada, a menos que o pacote conste da sua lista de permissões. A nossa equipa de investigação mapeou recentemente o quão estranho e perigoso é este potencial caminho de ataque.
Tudo isto já está incluído na versão 11.16.0 do npm, acompanhado de avisos, para que possa verificar o que deixa de funcionar antes de atualizar.
As vulnerabilidades pós-instalação que a alteração do npm corrige
Quase todos os worms e programas de roubo de credenciais que afetaram o npm desde o outono passado foram executados durante a instalação, e não em tempo de execução. O padrão geralmente envolve um atacante que primeiro assume o controlo de um pacote de confiança, normalmente através de phishing da conta npm de um mantenedor ou do roubo de um token de publicação. Em seguida, os atacantes publicam uma nova versão com um script pós-instalação adicionado ao ficheiro package.json, muitas vezes deixando o código-fonte original inalterado, para que nada pareça suspeito à primeira vista.
Quando alguém executa o comando «npm install», o npm executa esse script automaticamente na conta do utilizador. O script identifica a máquina, descarrega a carga útil real de um servidor do atacante, executa-a e apaga-se a si próprio, enquanto a carga útil procura tokens, chaves SSH e outros dados confidenciais, para depois os enviar
Nestes ataques, nem sequer é preciso utilizar o pacote malicioso ou importá-lo para se tornar uma vítima. Basta ter o azar de executar npm install enquanto o pacote estiver infetado.
Com a configuração padrão da v12 ativa, a instalação simplesmente pararia ao chegar ao pacote malicioso, a menos que esse pacote específico constasse na lista de permissões que definiu. O atacante ainda pode publicar a versão corrompida, mas numa máquina com a v12, esta permanece lá como ficheiros inativos na pasta `node_modules`.
Por que é que isto é importante
A onda de ataques com scripts pós-instalação começou no outono passado e, na verdade, ainda não parou. Vimos este ataque a um pacote da Red Hat há apenas uma semana. Alguns dos grandes ataques que tiraram partido desta vulnerabilidade e mantiveram os nossos investigadores de segurança acordados à noite incluem:
- Nx Singularity, agosto de 2025. Um token de publicação roubado disseminou versões maliciosas do Nx cujo script pós-instalação, telemetry.js, era executado durante a instalação. Este script recolhia tokens do GitHub, credenciais do npm, chaves SSH e carteiras de criptomoedas, e depois carregava-as para repositórios públicos do GitHub. As cerca de 2 300 credenciais que recolheu serviram de base para ataques futuros.
- Shai-Hulud, novembro de 2025. Um worm autorreplicante que afetou cerca de 500 pacotes nas plataformas Zapier, ENS, PostHog, Postman e AsyncAPI instalou o Bun runtime durante a configuração, executou o TruffleHog para extrair secrets e publicou-os em repositórios públicos do GitHub.
- O ataque ao axios, março de 2026. Uma conta de mantenedor que tinha sido comprometida distribuiu uma dependência cujo único objetivo era executar um gancho pós-instalação e instalar um RAT multiplataforma. O axios regista cerca de 100 milhões de downloads por semana.
- Mini Shai-Hulud, maio de 2026. Um worm derivado do Shai-Hulud original, que instalava um gancho de pré-instalação que extraía o ambiente de execução do Bun e executava um programa de roubo de credenciais. Ele propagou-se por mais de uma centena de pacotes no TanStack, UiPath e Mistral AI, tornando-se o primeiro worm do npm a publicar malware com uma proveniência de compilação válida.
Isto não é apenas um problema do npm, embora o npm seja o principal alvo. A mesma situação verifica-se noutros ecossistemas, como o Composer do PHP, onde mais de 200 versões do Laravel-Lang foram reescritas em maio para executar automaticamente um programa de roubo de credenciais através do autoloader (o Composer dispõe agora de filtragem nativa de malware, com tecnologia Aikido, para proteger os utilizadores a jusante).
O que fazer agora
Atualize para o npm 11.16.0 ou uma versão posterior, uma vez que as três alterações já estão implementadas, acompanhadas de avisos. Se já estiver a utilizar a versão 11.15.0 ou superior, --allow-git já está disponível, e --permitir-remoto desde a versão 11.15.0, pelo que já pode começar a configurá-las sem ter de esperar pela v12. Para os scripts, execute npm approve-scripts --allow-scripts-pending para ver o que seria bloqueado, aprovar os pacotes em que confia e aplicar as alterações package.json. O que quer que se ignore deixará de funcionar quando a v12 for lançada. Verifique isto, porque muitos pacotes legítimos utilizam scripts de instalação para compilações nativas e configuração e, assim que a configuração padrão mudar, essas instalações terão de ser aprovadas.
Também pode instalar o Safe Chain da Aikido, um wrapper seguro e gratuito para o npm, npx e yarn que se integra no seu fluxo de trabalho atual e verifica se cada pacote contém malware antes da instalação. Impede que instale malware acidentalmente e impõe um período de espera para novas versões de pacotes, o que evita que um grande número de pacotes comprometidos chegue ao seu dispositivo.
Boas configurações por predefinição protegem as pessoas que nunca abrem um registo de alterações (ou seja, quase toda a gente, na maioria das vezes, com exceção dos investigadores de segurança e dos devidamente cautelosos). O facto de o npm ter tornado esta opção segura por predefinição é a decisão certa. Não devia ter sido preciso um ano de caos público para que isso acontecesse, e não vai resolver tudo, mas estamos contentes por ter sido implementado.
