Investigadores de várias empresas de segurança identificaram no dia 4 de agosto de 2026 um ataque à cadeia de fornecimento de software que contaminou centenas de pacotes no registo npm com um worm de roubo de credenciais batizado de «ChainDrop». O ataque teve origem na compromissão da conta GitHub do responsável pela biblioteca keyv e propagou-se de forma automática a bibliotecas de armazenamento e cache extremamente populares, algumas com mais de 100 milhões de descarregamentos semanais. Trata-se de uma nova variante da família Shai-Hulud, com uma particularidade distintiva: usa a blockchain Ethereum para obter os endereços de comando e controlo.
Resposta rápida: O worm ChainDrop comprometeu mais de 400 pacotes npm (com contagens que investigadores estimam entre 435 e mais de 1.300, conforme a fonte e o momento) através de credenciais roubadas de manutentores. Rouba tokens npm, GitHub, chaves de cloud e segredos de CI/CD e republica-se sozinho. Se instalou uma versão afetada, trate a máquina como comprometida: remova primeiro os mecanismos de persistência, revogue (não apenas rode) todas as credenciais expostas a partir de um ambiente limpo e audite as suas contas npm e GitHub.
O que aconteceu e quando
De acordo com a equipa de investigação da Aikido, no dia 4 de agosto de 2026 os atacantes comprometeram a conta GitHub do manutentor por trás do keyv, uma biblioteca de armazenamento chave-valor com cerca de 127 milhões de descarregamentos semanais no npm, e usaram esse acesso para injetar um worm de roubo de credenciais em toda a família de pacotes. O mesmo manutentor detém o cacheable, o flat-cache, o file-entry-cache e outros utilitários de cache muito usados, todos apanhados no mesmo ataque.
A técnica de compromissão foi particularmente eficaz na ocultação. O ataque foi executado empurrando ficheiros maliciosos diretamente para o branch principal e cortando imediatamente uma nova versão, o que significa que as versões envenenadas foram publicadas no npm com proveniência válida assinada por GitHub Actions. Ou seja, os pacotes maliciosos surgiram com a marca de autenticidade que normalmente sinaliza um artefacto de confiança.
A Microsoft Threat Intelligence descreveu o mecanismo de propagação com detalhe: a rotina de propagação do payload descarrega a versão mais recente de cada publicador, insere-se, incrementa a versão de patch e publica o arquivo resultante — um mecanismo que pode transformar rapidamente uma única identidade npm comprometida em muitas versões maliciosas. Quanto ao vetor inicial, a Microsoft indica que as provas apontam para credenciais roubadas de manutentores como vetor de compromissão inicial e que a propagação posterior usou tokens de publicação npm roubados e, em fluxos de trabalho específicos, acesso de publicação via GitHub Actions OIDC.
A escala do ataque: números que divergem
As contagens variam consoante a empresa e o momento da medição, o que reflete o facto de o worm ainda estar ativo enquanto os investigadores publicavam. A Wiz confirma que o worm se propagou a mais de 400 pacotes npm distintos. A Semgrep contabilizou 1.557 versões envenenadas em 435 pacotes e muitos scopes de manutentores não relacionados, num surto de duas horas. A StepSecurity, por seu lado, reportou uma escala superior: um worm auto-propagante que envenenou 444 pacotes e 2.212 versões em menos de quatro horas, começando com [email protected]. Entretanto, a Aikido chegou a referir pelo menos 868 pacotes em 1.381 versões comprometidos pelo worm.
A imprensa especializada avançou ainda contagens mais elevadas. Importa reter que estas diferenças resultam da janela de observação e do critério (pacotes distintos vs. versões vs. downloads), e não necessariamente de contradições. O denominador comum é claro: falamos de pacotes fundacionais do ecossistema JavaScript. A StepSecurity detalha que a lista inclui [email protected] (mais de 150 milhões de descarregamentos semanais), [email protected] (149,9 milhões) e [email protected] (147,6 milhões).
Como funciona o payload
O padrão de infeção é consistente entre versões. Segundo a BleepingComputer, os pacotes envenenados contêm dois ficheiros — o dropper setup.mjs e o script Math_Symbol.js para roubo de informação sensível — bem como uma entrada "preinstall": "node setup.mjs" no ficheiro package.json. O gancho preinstall garante execução automática assim que se corre npm install.
A técnica de evasão passa por trocar de runtime. Como explica a Cyber Kendra, a primeira fase, setup.mjs, descarrega um runtime Bun autónomo (v1.3.13) diretamente das releases do GitHub, sem qualquer verificação de checksum ou assinatura, e usa-o para executar a segunda fase; correr o payload sob Bun em vez de Node contorna as ferramentas que só vigiam processos Node. A segunda fase é um aspirador de credenciais: acede aos metadados de instância AWS em 169.254.169.254, lê tokens do Vault, tokens de service account do Kubernetes, segredos GCP e Azure, tokens npm, e corre uma varredura de expressões regulares tipo TruffleHog à procura de qualquer coisa com aspeto de chave no disco.
Há duas novidades que tornam esta variante especialmente difícil de conter. A primeira é o comando e controlo baseado em blockchain. A Aikido descreve que se o carregamento para o GitHub falhar, o payload recorre a um domínio de fallback registado a 22 de maio de 2026 que aparenta não ter fim legítimo, obtido dinamicamente a partir de um smart contract Ethereum, permitindo ao atacante rodar a infraestrutura a qualquer momento sem tocar no payload. A segunda é a persistência através de ferramentas de desenvolvimento com IA. Segundo a Upwind, um gancho preinstall corre node setup.mjs no npm install; uma entrada em .vscode/tasks.json com runOn: folderOpen dispara quando um programador abre o repositório no VS Code; e um gancho SessionStart em .claude/settings.json dispara quando uma sessão de agente arranca no projeto.
Isto tem uma implicação prática crucial: a razão por que --ignore-scripts não fecha a exposição é que os ganchos de IDE e de agente estão cruzados — .claude/settings.json invoca node .vscode/setup.mjs e .vscode/tasks.json invoca node .claude/setup.mjs, pelo que apagar apenas uma diretoria deixa a outra capaz de re-disparar toda a cadeia.
Cronologia
| Hora (UTC, 4 ago 2026) | Evento |
|---|---|
| ~09:00 | Atacante introduz payloads de persistência em IDE no repositório keyv |
| 09:35 | Publicação de [email protected] com gancho preinstall — primeira release maliciosa conhecida |
| ~09:41 | Scanner da Socket sinaliza o pacote (cerca de seis minutos depois) |
| 09:40–11:44 | Surto de propagação de ~2 horas com 1.557 versões maliciosas (Semgrep) |
| ~20:00 | Manutentor recupera acesso à conta GitHub e inicia auditoria completa |
A cronologia baseia-se em dados da Wiz, que refere que a partir das 9:00 UTC o atacante usou primeiro uma identidade comprometida para introduzir payloads de persistência em IDE no repositório keyv e, pouco depois, publicou uma nova versão do keyv com o payload, worm que desde então se propagou a mais de 400 pacotes npm distintos. A CSO Online indica que o programador recuperou o acesso à sua conta GitHub por volta das 20:00 UTC e disse estar a fazer uma auditoria completa.
Indicadores de comprometimento (IOCs)
- Ficheiros no disco:
setup.mjs,Math_Symbol.jsoumath_init.js - Diretorias temporárias
/tmp/bun-dl-*e execução do processo Bun em máquinas que não usam Bun - Ganchos de autostart em
.claude/e.vscode/; scriptgh-token-monitor.sh, LaunchAgent plist e unidade systemd de utilizador - User-agent
Bun/1.3.13em chamadas de rede - Repositórios GitHub criados com a descrição
Shai-Hulud: Here We Go Again
A Kodem alerta ainda para um pormenor de ordem operacional: o pacote embute a string IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClients, uma linha de extorsão destinada a desencorajar a revogação de tokens, nova nesta vaga e sem qualquer peso técnico. Por outras palavras, não deve dissuadir a revogação de credenciais.
Mitigação e resposta
A ordem das ações importa. A Cyber Kendra recomenda remover primeiro o «dead-man’s switch» — verificar gh-token-monitor.sh, o LaunchAgent plist, a unidade systemd, as diretorias /tmp/bun-dl-*, os ficheiros Math_Symbol.js ou math_init.js e os ganchos de autostart .claude/.vscode, assumir que existe um monitor equivalente para o token npm, e só depois revogar (não apenas rodar) os tokens npm e GitHub, seguidos de AWS, GCP, Azure, Vault, Kubernetes e segredos de CI. A Microsoft reforça que as organizações devem revogar e rodar credenciais expostas a partir de um ambiente reconhecidamente limpo e reconstruir os sistemas afetados e artefactos a jusante a partir de fontes de confiança.
Há um fator atenuante relevante. Segundo a Kodem, o npm 12 e versões mais recentes não executam ganchos preinstall por defeito, pelo que ambientes já em npm 12 ou posterior não foram infetados pela via de instalação — mas permaneceram expostos através dos ganchos de IDE e de agente. Como caça de ameaças, a Kodem sugere procurar em três lugares, por esta ordem: as versões maliciosas nos lockfiles, os hashes dos ficheiros de payload no disco, e a execução do processo Bun em máquinas que não usam Bun — sendo esta última o indicador de maior sinal num CI runner, já que uma biblioteca de cache não tem razão para introduzir um segundo runtime JavaScript.
Porque é que isto importa em Portugal
Este incidente é um caso de manual de risco na cadeia de fornecimento de software, um dos vetores expressamente visados pela diretiva NIS2 e pela sua transposição nacional. O novo Regime Jurídico da Cibersegurança obriga muitas entidades a gerir a segurança da cadeia de aquisição de software e a notificar incidentes significativos ao CNCS/CERT.PT dentro de prazos apertados. Para PME portuguesas que dependem de pipelines de CI/CD e de dependências npm — o que é a norma no desenvolvimento web moderno —, um único build comprometido pode expor segredos de cloud, tokens de acesso e dados de clientes.
Quando o roubo de credenciais abre caminho ao acesso a dados pessoais, entra também em cena o RGPD, que pode obrigar à notificação à CNPD em 72 horas em caso de violação de dados com risco para os titulares. A recomendação transversal para organizações em Portugal é pragmática: fixar dependências a versões conhecidas com lockfiles e hashes de integridade, desativar a execução de scripts na instalação, atrasar a adoção de versões acabadas de publicar, e adotar publicação de confiança com credenciais efémeras em vez de tokens estáticos de longa duração.
Perguntas frequentes
O que é o worm ChainDrop?
É um worm auto-propagante de roubo de credenciais, descendente da família Shai-Hulud, que a 4 de agosto de 2026 contaminou centenas de pacotes npm a partir da conta GitHub comprometida do manutentor do keyv. Rouba tokens npm e GitHub, chaves de cloud e segredos de CI/CD e republica-se automaticamente. O nome deriva do uso da blockchain Ethereum para comando e controlo.
Como sei se fui afetado?
Procure nos lockfiles versões maliciosas dos pacotes afetados (keyv, flat-cache, file-entry-cache, cacheable, entre outros), verifique no disco os ficheiros setup.mjs e Math_Symbol.js, e caça a execução de processos Bun em máquinas que não usam Bun. Verifique também repositórios GitHub criados sem a sua autorização com a descrição «Shai-Hulud: Here We Go Again».
A flag –ignore-scripts protege-me?
Reduz o risco pela via de instalação, mas não fecha totalmente a exposição, porque o malware também planta persistência em ferramentas de desenvolvimento com IA. Abrir um repositório infetado no VS Code ou iniciar uma sessão do Claude Code pode re-disparar o payload sem necessidade de instalação. Ambientes em npm 12 ou superior não executam ganchos preinstall por defeito, mas continuam expostos por essa via.
O que devo fazer se instalei uma versão afetada?
Trate a máquina como comprometida. Remova primeiro os mecanismos de persistência e o monitor de tokens, depois revogue — não apenas rode — todas as credenciais expostas (npm, GitHub, AWS, GCP, Azure, Vault, Kubernetes e segredos de CI) a partir de um ambiente limpo, e reconstrua os sistemas afetados a partir de fontes de confiança. Audite as suas contas npm e GitHub por versões e repositórios inesperados.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente por Microsoft Threat Intelligence, Wiz, Aikido Security, StepSecurity, Upwind, Kodem, Expel e Semgrep.