GitHub desativa scripts de execução automática no npm
Aprofundamento CEVIU
Aprofundamento
A partir de julho de 2026, o npm 12 desativa por padrão os scripts preinstall, install e postinstall, não só em pacotes diretos, mas também em dependências transitivas. A mudança é uma resposta direta a ataques reais na cadeia de suprimentos: campanhas como as que comprometeram eslint-config-prettier, os pacotes Picasso da Toptal e a família Shai-Hulud usaram exatamente esses scripts para executar código malicioso durante npm install. O npm passa de um modelo de confiança implícita para um de aprovação explícita: cada script precisa ser registrado em package.json via npm approve-scripts, com avisos já ativos desde a versão 11.16.0.
O bloqueio se estende a vetores menos óbvios: dependências Git são proibidas por padrão (a menos que autorizadas com --allow-git), e URLs remotas como tarballs HTTPS exigem --allow-remote. Isso fecha falhas exploradas em ataques recentes onde arquivos .npmrc em repositórios Git sobrescreviam o binário git local. O npm é o último grande gerenciador a adotar essa postura, Yarn, pnpm e Bun já bloqueavam scripts de terceiros há anos.
Por que isso importa
Essa mudança reduz drasticamente a superfície de ataque mais explorada no ecossistema JavaScript: a execução automática de código durante instalação. Um único pacote comprometido em qualquer nível da árvore de dependências não consegue mais rodar payloads sem permissão explícita. Isso afeta diretamente equipes que usam CI/CD com npm install não auditado, desenvolvedores que instalam bibliotecas sem revisar seu package.json, e projetos que dependem de compilações nativas via node-gyp ou scripts prepare de dependências locais ou linkadas. Não é só sobre segurança teórica, é sobre impedir que ataques como os de roubo de credenciais, mineração de criptomoedas e backdoors em pipelines de produção continuem funcionando com o mesmo padrão simples de npm install.
Impacto para desenvolvedores
Desenvolvedores precisam atualizar para npm 11.16.0 agora para ver avisos antecipados nos fluxos afetados. O comando npm approve-scripts --allow-scripts-pending lista todos os scripts pendentes de aprovação; npm approve-scripts grava a lista aprovada em package.json. Projetos que usam node-gyp, dependências Git ou tarballs remotos quebrarão silenciosamente no npm 12, exigindo flags explícitas ou ajustes na configuração. Equipes devem auditar suas dependências com npm ls --all --depth=10 e testar builds locais e em CI com NPM_CONFIG_ALLOW_SCRIPTS=false para simular o comportamento do npm 12. Ignorar isso gera falhas de build inesperadas em julho de 2026, não erros de segurança, mas interrupções operacionais reais.
Perguntas frequentes
Quando o npm 12 será lançado e o que muda exatamente?
O npm 12 será lançado em julho de 2026. Ele desativa por padrão os scripts preinstall, install e postinstall de todas as dependências, diretas e transitivas. Também bloqueia dependências Git e URLs remotas (como tarballs HTTPS) a menos que autorizadas com --allow-git ou --allow-remote. A execução passa de automática para explícita via npm approve-scripts.
Por que o npm está fazendo isso agora?
Porque scripts de instalação são a maior superfície de execução de código malicioso no ecossistema npm. Ataques reais, como os contra eslint-config-prettier, Picasso e Shai-Hulud, usaram exatamente esses scripts para roubar dados, minerar criptomoedas e injetar backdoors. O npm era o último grande gerenciador a permitir isso por padrão; Yarn, pnpm e Bun já bloqueavam scripts de terceiros há anos.
Como saber se meu projeto será afetado pelo npm 12?
Atualize para npm 11.16.0 ou superior agora. Execute npm install e observe os avisos sobre scripts bloqueados. Use npm approve-scripts --allow-scripts-pending para listar todos os scripts pendentes. Projetos que usam node-gyp, dependências Git, tarballs remotos ou scripts prepare de dependências locais/linkadas serão impactados. Teste com NPM_CONFIG_ALLOW_SCRIPTS=false para simular o comportamento do npm 12.
O npm 12 elimina todos os riscos da cadeia de suprimentos?
Não. A mudança bloqueia apenas a execução automática de scripts durante a instalação. Ataques ainda podem ocorrer por meio de código malicioso executado em tempo de execução, contas de mantenedores comprometidas, typosquatting, confusão de dependências ou GitHub Actions comprometidos. É um avanço crítico, mas não uma solução completa.
- Categoria
- CEVIU Segurança da Informação
- Publicado
- 12 de junho de 2026
- Fonte
- CEVIU Segurança da Informação
