A 4 de agosto de 2026, um atacante assumiu o controlo da conta do GitHub do mantenedor do keyv, uma biblioteca de cache de chave-valor com cerca de centenas de milhões de downloads semanais no npm, e injetou um worm destinado a roubar credenciais em toda a família de pacotes do mantenedor, incluindo o cacheable, o flat-cache, o file-entry-cache e o cache-manager. Conhecido como ChainDrop, o worm propagou-se a centenas de pacotes adicionais, com um total combinado de mais de dois mil milhões de instalações mensais.
O que torna isto perigoso não é o número de downloads, mas sim a forma como o código malicioso ganhou confiança. O atacante publicou através do próprio pipeline de lançamento automatizado do projeto, pelo que as versões adulteradas apresentavam uma proveniência válida: uma prova assinada de que um pacote tinha sido compilado pelo pipeline oficial a partir da fonte verdadeira. Essa prova destina-se a ser um sinal de segurança. Neste caso, era genuína, porque o próprio pipeline tinha sido comprometido. Para um programador, ou para uma ferramenta de segurança que verificasse a assinatura, a versão maliciosa parecia completamente autêntica.
O ChainDrop é a mais recente vaga de uma campanha que os investigadores têm vindo a acompanhar desde setembro de 2025: Shai-Hulud 1.0 (setembro de 2025), 2.0 (novembro de 2025) e Mini Shai-Hulud, Quarta Vaga (maio de 2026). Cada uma delas tem vindo a intensificar-se, com as variantes mais recentes a apresentarem uma propagação mais agressiva e explorações mais abrangentes da cadeia de abastecimento.
O que sabemos até agora (6 de agosto de 2026)
- Data: «keyv@6.0.0» é a data de início confirmada, publicada a 4 de agosto de 2026.
- Ponto de entrada: A intrusão teve início com a conta de um responsável pela manutenção no GitHub que foi comprometida, e a versão maliciosa passou pelo pipeline de publicação legítimo do projeto.
- Dimensão: Os números variam consoante o sistema de monitorização, mas todos os relatórios concordam que se tratou de um incidente de grande envergadura na cadeia de abastecimento do npm. A StepSecurity comunicou, numa fase inicial, 435 pacotes / 1 557 versões, enquanto a Aikido e relatórios posteriores elevaram o total, com algumas estimativas a apontar para mais de 1 300 pacotes e cerca de 2 mil milhões de downloads mensais.
- Carga útil: Existe um caminho de pré-instalação que utiliza o ficheiro setup.mjs, o qual descarrega o Bun e executa uma carga útil de grandes dimensões, ofuscada, destinada a roubar credenciais.
- Atribuição: Os investigadores classificam-no como pertencente à família de malware Shai-Hulud.
Um sistema fiável usado contra si próprio
O que torna o ChainDrop particularmente preocupante é o facto de não ter recorrido a uma vulnerabilidade ostensiva nem a um site de downloads falso. Em vez disso, tirou partido da cadeia de abastecimento normal de software — o mesmo processo de publicação e instalação de pacotes utilizado por milhões de programadores.
Na prática, isso significa que um pacote pode parecer legítimo, mas conter, sem dar nas vistas, código malicioso que se ativa durante a instalação. As equipas de segurança afirmam que o malware foi concebido para roubar informações confidenciais dos computadores dos programadores e dos sistemas de CI/CD, incluindo tokens do GitHub, credenciais do npm, chaves da AWS, segredos do Kubernetes e outros dados de acesso.
O risco mais alargado não se limita aos programadores. Qualquer organização que utilize pacotes afetados pode ser indiretamente afetada através de sistemas de compilação, dependências e pipelines de lançamento automatizados.
O ChainDrop serve para nos lembrar que as dependências de código aberto representam um risco empresarial, e não apenas uma preocupação dos programadores.
Um risco empresarial, não apenas um risco para os programadores
Para qualquer organização que dependa de software JavaScript e Node.js, o ChainDrop serve para nos lembrar que as dependências de código aberto constituem um risco empresarial, e não apenas uma preocupação dos programadores.
Um pacote comprometido pode ser herdado indiretamente através de dependências e sistemas de compilação, podendo levar ao roubo de credenciais, ao acesso não autorizado à infraestrutura na nuvem e à rotação de segredos e resposta a incidentes em grande escala. Quando a integridade do software, o controlo de acesso e o risco associado a terceiros se enquadram no seu ambiente de controlo — tal como acontece no âmbito das normas PCI DSS, DORA, NIS2 e CMMC —, essa exposição recai diretamente também sobre a conformidade e a governação.
Ações imediatas recomendadas
Se tiver instalado um pacote afetado a partir de 4 de agosto de 2026:
- Analise as suas dependências: gere uma SBOM e analise as dependências em relação a versões conhecidas como maliciosas
- Imagem antes da revogação: Imagem dos sistemas afetados antes da rotação dos tokens. O malware está atento à revogação de credenciais e pode ativar um manipulador se a rotação for efetuada primeiro.
- Alternar os dados confidenciais expostos: Alternar todos os dados confidenciais acessíveis (tokens do npm, PATs do GitHub, chaves SSH, credenciais na nuvem) e aplicar a autenticação multifator (MFA)
- Verificar pela versão exata, e não pelo nome: procurar a versão exata já identificada, e não o nome do pacote; as etiquetas do registo foram alteradas durante o incidente
- Remova os hooks ao nível do repositório: verifique os ficheiros .claude/settings.json e .vscode/tasks.json, e não apenas o diretório node_modules
- Auditoria de CI/CD: Realizar uma auditoria ao CI/CD e ao GitHub Actions para detetar publicações inesperadas ou novos fluxos de trabalho
Identificar a sua exposição com uma SBOM
A dificuldade reside na visibilidade: as versões adulteradas encontram-se nas camadas mais profundas das árvores de dependências e parecem autênticas. Quando analisámos os pacotes afetados com o SBOM no MetaDefender ™ Software Supply Chain, as versões comprometidas foram sinalizadas, em vez de serem consideradas fiáveis com base na sua proveniência.
A lição a reter é que a defesa eficaz contra este tipo de ataque consiste em verificar o conteúdo de um componente, em vez de confiar na sua origem.
Principais conclusões
- A proveniência comprova a origem, não a integridade. Uma assinatura válida numa cadeia de distribuição comprometida continua a produzir um pacote malicioso assinado. Verifique o conteúdo, não apenas as certificações.
- A instalação já não é o único fator desencadeante. Os hooks do IDE e do agente ao nível do repositório podem ser executados no momento da abertura. Alargue a sua revisão para além do «npm install».
- Esta campanha continua em curso. O ChainDrop representa a mais recente onda de uma série de incidentes que tem vindo a intensificar-se desde setembro de 2025. Considerar qualquer incidente isolado como resolvido, sem abordar as lacunas subjacentes no fluxo de trabalho e na gestão de credenciais, deixa a porta aberta para o próximo incidente.
Proteja a sua cadeia de abastecimento com MetaDefender Software Supply Chain
