O engano na cadeia de fornecimento de npm: assim jscrambler 8.14.0 lançou um infostealer em segundos

O Pacote npm jscrambler@8.14. 0, publicado em 11 de julho de 2026, continha um gancho malicioso de pré-instalação que, com apenas executar npm install, moveva e executava um infostealer nativo multiplataforma sem necessidade de importar ou invocar a partir da linha de comandos: bastava instalar essa versão para que o código malicioso fosse executado no ambiente da instalação.

O erro foi detectado rapidamente por analistas externos, que encontraram dois ficheiros novos em dist/: um loader JavaScript (setup.js) e um recipiente binário (intro.js) que empacotou três executáveis nativos (Windows, macOS e Linux). O loader escolhia o binário segundo o SO, o escrevia com um nome aleatório no diretório temporal, o marcava como executável e o lançava em segundo plano com saída oculta. É especialmente relevante que esses arquivos apareciam no pacote publicado no npm, mas não no repositório público do projeto nem no histórico de releases: a versão 8.14.0 subiu diretamente ao registro usando uma conta de manutenção legítima, sem tag ou commit coincidente no GitHub, o que aponta para uma conta ou pipeline comprometido.

O payload, de acordo com as análises públicas, é um infostealer escrito em Rust que rastreia máquinas de desenvolvedor e runners de CI em busca de credenciais e segredos: chaves de nuvem (AWS, Azure, Google Cloud, incluindo metadata de instâncias/CI), tokens e sessões de serviços (Discord, Slack, Telegram, Steam), senhas e cookies de navegadores, bóvedas como Bitwarden, semente de carteiras e clientes de criptos (MetaMask, Phantom, Exodus) e configurações/API keys de ferramentas de IA e ambientes de desenvolvimento (por exemplo, integrações de Claude Desktop, Cursor, Windsurf, VS Code, Zed e servidores MCP). O Linux também detectou a capacidade de carregar um programa eBPF em memória, aumentando o risco para uma possível execução no kernel; as versões do Windows e macOS incorporam verificações anti- depuração e mecanismos de persistência (tareia escondida no Programador de Tarefas do Windows que se relança a cada minuto e um LaunchAgent no macOS).

A campanha também incluía comunicações de comando e controle criptografadas desde o binário, que em execução atingiu pelo menos dois endereços IP públicos observados por telemetria e infraestrutura de Tor, o que complica o rastreamento. Se o seu ambiente instalou jscrambler@8.14.0 entre a hora de publicação e o seu destacamento por pesquisadores, o binário já pôde ter extraído segredos nesses segundos ou minutos críticos; o desenho do ataque aproveita precisamente o fato de que jscrambler é usado em tempo de construção e CI, pelo que as credenciais que esses processos podem acessar eram o objetivo principal, não o número de downloads.

Acções imediatas: se você gerencia projetos ou infraestruturas que usam npm, busca em lockfiles, registros de gestores de pacotes e logs de CI qualquer referência a jscrambler@8.14. 0 ou à execução de dist/setup.js a partir de 11 de julho de 2026; o loader deixa um executável com nome aleatório na pasta temporária, pelo que será necessário correlacionar marcas temporárias de instalação com processos filhos de Node.js e execuções em /tmp (Linux/macOS) ou %TEMP% (Windows). Em máquinas Windows inspecione o Programador de Tarefas para tarefas ocultas e no macOS revisa ~/Library/LaunchAgents por plists não autorizados. Se confirmar a execução, assume que todos os segredos acessíveis foram exfiltrados e procede imediatamente a rodar: chaves de nuvem (AWS, Azure, GCP), tokens do GitHub e npm, API keys de ferramentas de IA e MCP, revogação de sessões no Slack/Discord/outros, reseteo de credenciais em vaults e mover qualquer cripto fora de carteiras que residiam na máquina comprometida.

Não basta remover o ficheiro de lixo: limpa caches e lockfiles que apontem para a versão comprometida, remove jscrambler@8.14.0 de repositórios de artefatos e proxies de registo, e actualiza uma versão limpa (o ramo publica mostrou 8.15.0 sem o hook e outra opção segura é fixar a 8.13.0). Além disso, verifique o cliente npm empregado em ambientes: npm 12 introduziu que os programas de instalação ficam desactivados por defeito, salvo aprovação explícita, o que atenua este vetor em clientes recentes; contudo, clientes antigos continuam a executá-los automaticamente, pelo que os pipelines e máquinas locais com clientes antigos continuam em risco.

Medidas estratégicas a médio prazo: forçar 2FA e políticas de publicação mais rigorosas em contas de manutenção, limitar o alcance de tokens de CI e empregar credenciais efímeras para processos de build e implantação; usar assinaturas de pacotes e cadeias de fornecimento verificáveis (por exemplo, com soluções como Sigstore) e modelos de integridade de supply chain como SLSA para aumentar a confiança em artefatos publicados. Também é conveniente implantar repositórios de pacotes cacheados ou privados que permitam controle e revisão antes de pacotes externos entrem em builds críticos, e monitorar automaticamente diffs entre o conteúdo publicado no registro e o que o repositório de código-fonte mostra como release/tags.

A história de eventos se encaixa com outras campanhas recentes que exploraram contas comprometidas ou processos de publicação para infiltrar código malicioso em pacotes populares; para proteger, além das rotações de credenciais e contenção de incidentes, planeja uma resposta à cadeia de fornecimento que inclua detecção de anomalias em subidas a registries, revisão humana de mudanças em dist/ antes que a CI confie neles, e políticas que evitem que npm install em ambientes sensíveis corra com privilégios desnecessários.

Fontes úteis para compreender e mitigar riscos na cadeia de fornecimento de pacotes podem ser encontradas na documentação do GitHub sobre segurança da cadeia de fornecimento e em projetos de assinatura de artefatos como a Sigstore; revisa também a página oficial do pacote em npm para confirmar a história de versões e o estado de publicação: Guia do GitHub sobre segurança da cadeia de fornecimento, Sigstore, Página de jscrambler em npm.

Indicadores técnicos já divulgados por aqueles que analisaram o incidente incluem os endereços IP observados na etapa de exfiltração (por exemplo, 37.27.122.124 e 57.128.246.79), artefatos temporários com nomes aleatórios nas pastas temporárias e persistência por tarefas agendadas no Windows ou LaunchAgents no macOS; usa esses indicadores como parte da contenção de rede e resposta forense. Se precisar de ajuda operacional para avaliar o alcance, realizar rotações coordenadas de credenciais ou limpar pipelines da CI, considera escalar uma equipe de resposta a incidentes com experiência em compromissos da cadeia de abastecimento.