Um ataque de grandes proporções contra a cadeia de suprimentos de software colocou novamente o ecossistema npm em alerta. Um worm autorreplicante associado inicialmente ao pacote Keyv conseguiu comprometer centenas de pacotes e milhares de versões, enquanto buscava credenciais capazes de ampliar automaticamente a própria propagação.
A campanha, rastreada por pesquisadores como ChainDrop, ganhou visibilidade em 4 de agosto de 2026 e chamou atenção não apenas pela velocidade de disseminação. O malware também manipula arquivos de configuração utilizados pelo Claude Code, da Anthropic, e pelo Visual Studio Code, criando caminhos para execução do código malicioso dentro do ambiente de desenvolvimento.
O episódio representa uma evolução importante nos ataques de supply chain: comprometer uma dependência deixa de ser apenas uma forma de atingir aplicações e passa a oferecer uma porta de entrada para estações de desenvolvedores, pipelines de CI/CD, credenciais de nuvem e até ferramentas de programação baseadas em inteligência artificial.
Ataque começou com o Keyv
Uma das primeiras versões associadas à campanha foi a keyv@6.0.0. O Keyv é uma biblioteca JavaScript de armazenamento chave-valor utilizada no ecossistema Node.js.
Segundo análise da Cycode, o invasor comprometeu a conta GitHub do mantenedor responsável pelo Keyv e por pacotes da família Cacheable. O mantenedor, portanto, é vítima do incidente, e não participante da operação.
A partir do acesso comprometido, código malicioso chegou aos processos legítimos de publicação.
Entre os pacotes inicialmente identificados estavam keyv, cacheable, cacheable-request, cache-manager, flat-cache, file-entry-cache e diferentes componentes do namespace @cacheable.
Mas a característica mais perigosa do ataque estava no que acontecia depois.
Malware foi projetado para continuar se espalhando
Diferentemente de um pacote malicioso convencional, que infecta quem instala determinada versão, o ChainDrop apresenta comportamento de worm.
Isso significa que ele procura condições para continuar se propagando automaticamente.
Depois de alcançar um ambiente, o malware tenta localizar credenciais de desenvolvimento e publicação. Se encontrar tokens com permissões suficientes, pode utilizá-los para contaminar outros pacotes aos quais aquela vítima possui acesso.
A sequência cria um efeito em cadeia:
pacote comprometido → desenvolvedor infectado → credenciais roubadas → novos pacotes comprometidos → novas vítimas.
Esse mecanismo explica a velocidade com que o incidente ultrapassou os projetos inicialmente comprometidos.
A StepSecurity chegou a registrar 435 pacotes e mais de 1.550 versões comprometidas durante a evolução inicial da campanha.
Outros levantamentos continuaram registrando números ainda maiores à medida que novas amostras eram identificadas. Dados acompanhados pela Socket chegaram a 444 pacotes únicos e 2.234 artefatos afetados, mostrando por que números diferentes aparecem em relatórios sobre o mesmo incidente.
Por isso, a quantidade deve ser tratada como um retrato de um incidente em evolução, e não como um número definitivo.
Claude Code entrou na estratégia de persistência
Um dos elementos que diferencia essa campanha de ataques anteriores ao npm é o uso de arquivos associados a ferramentas modernas de desenvolvimento.
Segundo a Cycode, o malware manipula o arquivo:
.claude/settings.json
Esse arquivo pode definir configurações utilizadas pelo Claude Code.
O ataque adiciona um mecanismo associado ao início da sessão, criando uma oportunidade para executar o payload malicioso quando o ambiente é utilizado.
Isso não significa que uma vulnerabilidade do Claude Code esteja sendo explorada.
A lógica é diferente.
O invasor compromete o repositório e coloca nele uma configuração que será interpretada por uma ferramenta legítima.
O aplicativo confiável acaba servindo como mecanismo para disparar o código plantado pelo atacante.
VS Code também pode acionar o malware
A campanha utiliza conceito semelhante contra o Visual Studio Code.
Nesse caso, arquivos relacionados a tarefas do workspace podem ser manipulados por meio de:
.vscode/tasks.json
Os mecanismos encontrados pelos pesquisadores foram construídos de maneira que configurações do Claude Code e do VS Code interajam com os componentes maliciosos plantados no projeto.
Isso traz uma consequência especialmente preocupante.
Em determinados cenários, nem mesmo executar npm install é necessário para ativar o caminho malicioso.
A simples interação com um repositório contaminado em uma ferramenta configurada para confiar e interpretar esses arquivos pode representar risco.
Ataque mostra novo risco dos agentes de IA
O uso do Claude Code acrescenta uma dimensão importante à segurança de agentes de inteligência artificial.
Ferramentas de programação baseadas em IA deixaram de ser apenas interfaces que sugerem trechos de código.
Agentes modernos podem ler projetos, editar arquivos, utilizar terminal, executar comandos e interagir com ferramentas externas.
Essas capacidades são justamente o que torna os agentes úteis.
Mas também aumentam o impacto de configurações maliciosas presentes em um repositório.
Para as equipes de segurança, surge uma nova pergunta:
o que um projeto pode fazer quando é aberto por um agente de IA com permissões para executar ferramentas?
O ChainDrop demonstra que esse cenário já deixou de ser apenas teórico.
Worm procurava credenciais valiosas
O objetivo do malware não era simplesmente manter acesso ao computador.
A campanha foi construída para procurar credenciais com alto valor operacional, especialmente aquelas utilizadas no desenvolvimento e publicação de software.
Esses segredos podem permitir acesso a repositórios, serviços de nuvem, pipelines automatizados e outros pacotes npm.
O comprometimento de uma estação de desenvolvimento é especialmente perigoso porque esse computador frequentemente possui conexões privilegiadas com vários outros ambientes.
Um desenvolvedor pode ter acesso a GitHub, npm, servidores internos, AWS, Azure, Google Cloud, bancos de dados e plataformas CI/CD.
Roubar essas credenciais transforma uma única máquina comprometida em uma possível ponte para dezenas de sistemas.
Malware ainda possuía capacidade de execução remota
A análise técnica da Cycode identificou outro recurso preocupante.
Dados roubados eram preparados para exfiltração e enviados para infraestrutura controlada pelo operador. Uma resposta do servidor de comando e controle poderia incluir código adicional para execução no processo comprometido.
Isso oferece ao invasor capacidade de adaptar o comportamento do malware depois da infecção inicial.
A infraestrutura também utilizou um contrato Ethereum como parte do mecanismo para localizar recursos de comando e controle, estratégia que pode aumentar a resiliência da operação.
Há um risco ao simplesmente revogar credenciais
Uma das descobertas mais incomuns da investigação envolve um mecanismo que monitora tokens do GitHub.
Segundo a Cycode, o malware instala, em determinados ambientes Linux ou macOS, um componente que verifica periodicamente se o token roubado continua válido.
Quando detecta que a credencial foi revogada — por exemplo, porque a empresa iniciou sua resposta ao incidente — o mecanismo pode disparar uma ação configurada pelo atacante.
Isso muda a ordem tradicional de resposta.
Normalmente, uma das primeiras recomendações depois do roubo de credenciais seria revogar imediatamente todos os tokens.
Neste incidente, organizações potencialmente comprometidas precisam primeiro identificar e neutralizar esse mecanismo de persistência antes de executar uma rotação ampla de credenciais.
Pacotes tinham proveniência válida
Talvez uma das lições mais importantes do ChainDrop esteja relacionada à confiança nos mecanismos de assinatura.
Algumas versões contaminadas chegaram ao npm com proveniência válida associada ao processo legítimo de publicação pelo GitHub.
À primeira vista, isso parece contraditório.
Se o pacote foi publicado por um pipeline legítimo e possui evidências criptográficas de sua origem, como pode conter malware?
Porque proveniência e segurança são conceitos diferentes.
A proveniência comprova de onde determinado artefato veio e como ele foi construído.
Ela não garante que o código enviado ao pipeline estava livre de comprometimento.
Se o invasor controla o código antes da construção, o pipeline legítimo pode produzir e publicar um pacote perfeitamente autenticado — mas malicioso.
Supply chain depende de confiança
O episódio evidencia uma característica estrutural do desenvolvimento moderno.
Aplicações raramente são construídas inteiramente com código produzido internamente.
Um projeto utiliza dezenas de bibliotecas.
Essas bibliotecas dependem de outras.
E essas dependências possuem suas próprias dependências.
Um desenvolvedor pode executar código pertencente a projetos que nunca conheceu diretamente.
Essa estrutura permite acelerar drasticamente o desenvolvimento, mas também cria uma enorme rede de confiança.
Ataques como o ChainDrop procuram transformar justamente essa confiança em mecanismo de propagação.
O número de downloads não representa número de vítimas
Pacotes relacionados à campanha possuem enorme alcance no ecossistema JavaScript.
A Cycode estima que o Keyv tenha aproximadamente 127 milhões de downloads semanais.
Esse número, porém, não significa que 127 milhões de computadores tenham sido comprometidos.
Métricas de download do npm incluem pipelines automatizados, caches, builds repetidos e instalações em diferentes ambientes.
Além disso, a versão maliciosa keyv@6.0.0 representou uma mudança de versão principal e não seria automaticamente instalada por projetos presos à linha 5.x.
Outros pacotes comprometidos, entretanto, receberam atualizações de patch compatíveis com intervalos de versões já utilizados por projetos, aumentando a possibilidade de atualização automática em determinadas configurações.
O que empresas precisam verificar
Organizações que utilizam Node.js devem verificar os arquivos de lock de seus projetos para identificar se alguma versão comprometida foi efetivamente resolvida.
Também é importante analisar estações de desenvolvimento e runners de CI/CD que instalaram pacotes suspeitos.
A investigação deve ir além de node_modules.
Como a campanha utiliza configurações de ferramentas, arquivos inesperados em diretórios .claude e .vscode também merecem atenção.
Além disso, equipes devem revisar tokens npm, credenciais GitHub, chaves de serviços de nuvem e outros segredos presentes nos sistemas potencialmente atingidos.
No caso específico desta campanha, entretanto, a ordem da resposta importa: a análise da Cycode recomenda neutralizar primeiro os mecanismos de persistência e o monitor de revogação antes de iniciar a rotação das credenciais.
Empresas brasileiras também estão dentro da superfície de risco
Não há evidências de que a campanha tenha como alvo específico organizações brasileiras.
Mas ataques à cadeia de suprimentos de código aberto são naturalmente globais.
Uma empresa no Brasil baixa os mesmos pacotes npm utilizados por organizações nos Estados Unidos, Europa ou Ásia.
Isso significa que a exposição não depende de o atacante escolher uma empresa brasileira como alvo.
A organização pode simplesmente estar dentro da cadeia de dependências atingida.
Para equipes brasileiras de desenvolvimento, o incidente reforça a importância de inventariar dependências, utilizar lockfiles, limitar privilégios de tokens, proteger pipelines e monitorar alterações em arquivos de configuração dos ambientes de desenvolvimento.
Agentes de IA entram definitivamente na superfície de ataque
O ChainDrop mostra que a segurança da cadeia de desenvolvimento está mudando rapidamente.
O que antes envolvia principalmente bibliotecas, gerenciadores de pacotes e pipelines de CI/CD agora precisa considerar também IDEs e agentes de inteligência artificial.
Um arquivo dentro de um repositório pode deixar de ser apenas informação.
Dependendo da ferramenta que o interpreta e das permissões disponíveis, pode se transformar em uma instrução operacional.
Esse é provavelmente o aspecto mais importante do incidente.
O ataque não explora somente vulnerabilidades técnicas. Ele explora a confiança entre desenvolvedor, repositório, pacote, pipeline, IDE e agente de IA.
Quanto mais automatizado se torna o desenvolvimento, mais importante será controlar exatamente quais ações essas ferramentas podem executar — e sob quais condições.
