Carregando conteúdo…
Segurança Digital
A campanha WEL1DROPPER publicou mais de mil componentes maliciosos no npm e mostrou que bloquear scripts de instalação não basta. Entenda como o ataque funciona, o que pode ser roubado e como responder.
Uma campanha em larga escala transformou o registro npm em uma esteira de distribuição de malware para Windows, macOS e Linux. O caso começou a chamar atenção em 5 de agosto de 2026, quando pesquisadores identificaram centenas de componentes ligados ao mesmo carregador. A contagem inicial de quase 800 pacotes cresceu e chegou a 1.033 componentes confirmados, segundo a atualização mais recente da investigação.
O número assusta, mas o aspecto mais importante está no modo de ativação. Parte dos pacotes não dependia dos conhecidos scripts preinstall ou postinstall. O código malicioso podia começar a trabalhar quando o desenvolvedor seguia o exemplo do README e importava a biblioteca com require(). Na prática, uma dependência aparentemente comum ganhava acesso ao mesmo ambiente do projeto, incluindo arquivos, variáveis e credenciais disponíveis naquele processo.
Isso muda a pergunta de segurança. Não basta verificar se um pacote executa algo durante a instalação. Também é preciso saber o que ele faz quando entra no código.
Em 5 de agosto, a Sonatype passou a acompanhar o grupo sob o nome Flooding Dropper. No dia seguinte, a OpenSourceMalware publicou uma análise da mesma operação, chamada por seus pesquisadores de WEL1DROPPER. Naquele momento, mais de 700 pacotes teriam sido publicados em cerca de 48 horas.
A escala aumentou rapidamente. A Sonatype relacionou 846 componentes à campanha, enquanto a Socket contabilizou 865 artefatos, correspondentes a 789 pacotes únicos. Em 11 de agosto, uma atualização citada pelo The Hacker News elevou o total confirmado para 1.033.
Esses números não são necessariamente contraditórios. Cada empresa pode contar versões, artefatos ou pacotes únicos de maneira diferente, e a remoção de publicações maliciosas acontece ao mesmo tempo em que novas amostras são descobertas. O que permanece claro é que não se tratava de um pacote isolado, mas de uma operação automatizada e distribuída entre várias contas descartáveis.
Os nomes misturavam termos técnicos, comerciais e palavras recorrentes em combinações que pareciam plausíveis à primeira vista. Pesquisadores descrevem parte desse padrão como AI slopsquatting, uma variação do typosquatting em que nomes estranhos ou sugeridos por ferramentas de IA podem ser registrados antes que o desenvolvedor perceba que aquela biblioteca nunca existiu de verdade.
O README completava a armadilha. Em vez de apresentar uma função claramente suspeita, ele ensinava a importar o módulo como qualquer SDK. A chamada carregava um arquivo auxiliar e iniciava a cadeia de infecção imediatamente.
Por isso, desativar scripts de instalação continua sendo uma boa camada de proteção, mas não bloquearia sozinho este ataque. O pacote poderia ficar quieto durante o npm install e agir durante um teste, uma inicialização local, uma compilação ou a execução do servidor.
Uma vez carregado, o primeiro estágio identificava o sistema operacional e a arquitetura do processador. Em seguida, tentava baixar um executável compatível com Windows, macOS ou Linux por diferentes endereços HTTPS.
Se a conexão direta falhasse, havia uma segunda rota: consultas DNS do tipo TXT. Fragmentos codificados do arquivo eram recuperados, reunidos e gravados em uma pasta temporária. O processo então era iniciado em segundo plano, separado do Node.js que havia feito a importação.
Essa separação é importante. Fechar o terminal, interromper o npm install ou encerrar a aplicação não garante que o binário baixado tenha parado. Ele pode continuar ativo, estabelecer persistência e buscar novos estágios.
As análises públicas descrevem comportamentos diferentes por plataforma:
O resultado possível combina acesso remoto, execução de novas cargas e roubo de informações. Isso coloca em risco tokens do npm e GitHub, chaves de serviços em nuvem, segredos de CI/CD e outros dados que costumam estar disponíveis em máquinas de desenvolvimento.
A campanha diluiu as publicações em diversas contas, muitas delas responsáveis por poucos pacotes. O código também recebia pequenas alterações de nomes de funções e variáveis, embora mantivesse o mesmo comportamento.
Essa estratégia aumenta o trabalho de moderação. Derrubar uma conta ou bloquear uma assinatura exata não encerra a operação. Quando centenas de variações aparecem quase ao mesmo tempo, listas de nomes conhecidos envelhecem rapidamente.
O caso também expõe um risco crescente do desenvolvimento assistido por IA. Um modelo pode sugerir um nome convincente que não corresponde a uma biblioteca real. Se alguém registrar esse nome com antecedência, uma recomendação inventada deixa de produzir apenas um erro e passa a apontar para código hostil.
Isso não significa que toda sugestão de IA seja perigosa. Significa que a recomendação não substitui a verificação do pacote, de seu autor e de sua origem.
Remover a dependência do package.json não é resposta suficiente caso ela tenha sido importada ou executada. A orientação da Sonatype é tratar o equipamento afetado como comprometido.
Uma resposta prudente segue esta ordem:
A troca de credenciais deve acontecer a partir de um dispositivo limpo. Fazer isso antes de remover o malware pode simplesmente entregar os novos segredos ao invasor.
Nenhuma ferramenta resolve sozinha um ataque à cadeia de software, mas algumas práticas reduzem bastante a superfície:
npm ci em automações para evitar mudanças inesperadas na árvore já aprovada;npm audit signatures quando disponíveis;npm audit para vulnerabilidades conhecidas, sem tratá-lo como detector completo de malware recém-publicado.A proveniência ajuda a confirmar onde e como uma versão foi gerada. Ela é uma evidência valiosa, mas não prova por si só que o comportamento do pacote é seguro. O código, as permissões e a necessidade real da dependência ainda precisam de revisão.
O WEL1DROPPER mostra que a confiança em uma dependência começa antes da instalação e continua durante a execução. Controles de scripts, listas de bloqueio e scanners são importantes, mas perdem força quando a armadilha usa nomes novos, muitas contas e código que só desperta no primeiro require().
Para equipes pequenas, a medida mais eficaz pode ser também a mais simples: adicionar menos dependências e entender cada nova biblioteca antes de incorporá-la. Para empresas, a mesma ideia precisa virar processo, com aprovação, observabilidade, ambientes descartáveis e resposta preparada para comprometimento de credenciais.
O registro npm remove pacotes maliciosos quando eles são identificados, mas a escala desta campanha deixa uma lição incômoda. Código aberto continua sendo essencial para o desenvolvimento moderno, porém importar uma biblioteca é conceder execução dentro do seu projeto. Essa decisão merece a mesma atenção dada a qualquer outro software instalado na máquina.
Apuração concluída em 23 de agosto de 2026. Os totais podem mudar conforme novas amostras são identificadas ou removidas do registro.