Um ataque contra o ecossistema npm mostrou como uma única dependência comprometida pode se transformar rapidamente em uma ameaça para centenas de projetos de software.
Uma nova campanha do worm ChainDrop, relacionado à família de ataques Shai-Hulud, contaminou centenas de pacotes publicados no npm e utilizou credenciais roubadas para continuar se propagando pela cadeia de suprimentos.
A campanha ganhou visibilidade em 4 de agosto de 2026, inicialmente relacionada ao pacote keyv@6.0.0 e ao ecossistema Keyv/Cacheable. Conforme a investigação avançou, pesquisadores identificaram que a contaminação havia alcançado pacotes pertencentes a diferentes organizações.
O ataque possui ainda uma característica particularmente importante para o atual cenário de desenvolvimento: além de explorar mecanismos tradicionais do npm, o malware criou caminhos de execução envolvendo ferramentas como Claude Code e Visual Studio Code.
Isso amplia a discussão sobre segurança da cadeia de software para um novo território: os arquivos de configuração que controlam IDEs e agentes de inteligência artificial.
O ataque começou pelo ecossistema Keyv
O Keyv é uma biblioteca JavaScript utilizada como armazenamento chave-valor e aparece direta ou indiretamente nas dependências de diversos projetos.
Segundo as investigações publicadas sobre o incidente, uma versão maliciosa identificada como keyv@6.0.0 entrou no npm durante o ataque.
Outros pacotes relacionados ao ecossistema Keyv e Cacheable também foram comprometidos.
O problema se tornou especialmente grave porque o malware não se limitava a executar uma carga maliciosa no computador da vítima.
Ele procurava credenciais que permitissem infectar outros pacotes npm.
Esse comportamento transformou a campanha em um worm de cadeia de suprimentos.
O que é um worm?
Um worm é um malware capaz de se propagar automaticamente.
Em ataques tradicionais de supply chain, criminosos podem comprometer um desenvolvedor e publicar manualmente uma versão maliciosa de determinado pacote.
O ChainDrop automatiza parte desse processo.
Depois de alcançar um ambiente de desenvolvimento, procura credenciais e recursos que possam permitir acesso a outros projetos e processos de publicação.
Quando encontra essas oportunidades, pode contaminar novos pacotes.
Esses pacotes são baixados por outras pessoas.
E o ciclo continua.
É justamente essa capacidade de autorreplicação que transforma um incidente envolvendo uma biblioteca em um problema potencialmente muito maior.
Centenas de pacotes foram contaminados
Os números mudaram rapidamente durante a investigação porque o worm continuava se espalhando enquanto pesquisadores analisavam a campanha.
Levantamentos iniciais encontraram dezenas e depois centenas de pacotes.
Análises posteriores da campanha ChainDrop apontaram 444 pacotes contaminados, distribuídos em grande número de releases maliciosos.
Alguns levantamentos contabilizaram mais de mil artefatos ou versões afetadas, o que explica diferenças entre números publicados durante os primeiros dias do incidente.
Por isso, é importante diferenciar pacotes únicos de versões/releases contaminados.
O impacto potencial também é expressivo porque os pacotes envolvidos acumulam, em conjunto, bilhões de downloads mensais.
Isso não significa que bilhões de computadores tenham sido infectados. Downloads de pacotes incluem sistemas automatizados, pipelines de CI/CD, instalações repetidas e outras operações.
Ainda assim, o número demonstra o tamanho da superfície potencial de exposição.
Malware procurava credenciais valiosas
Depois de executado, o ChainDrop procurava informações que poderiam permitir novos comprometimentos.
Entre os alvos estavam credenciais associadas ao desenvolvimento de software e infraestrutura em nuvem.
As análises identificaram interesse por tokens do GitHub, credenciais de serviços cloud, chaves privadas e segredos utilizados por ambientes de desenvolvimento.
Esse tipo de informação é extremamente valioso em um ataque de supply chain.
Uma credencial npm com permissão de publicação, por exemplo, pode permitir que criminosos lancem uma nova versão de um pacote legítimo.
Um token do GitHub pode oferecer acesso ao código-fonte ou aos workflows de determinada organização.
Credenciais de cloud podem abrir uma superfície de ataque ainda maior.
Worm também explorava GitHub Actions
A campanha mostrou atenção especial aos ambientes automatizados de desenvolvimento.
Pesquisadores da Unit 42, da Palo Alto Networks, analisaram mecanismos utilizados pelo ChainDrop para obter segredos de GitHub Actions runners.
A investigação identificou técnicas destinadas a recuperar informações sensíveis presentes na memória de processos dos runners, incluindo tokens e outros segredos utilizados durante workflows.
Isso é importante porque pipelines de CI/CD frequentemente possuem exatamente aquilo que um invasor precisa para transformar uma invasão em ataque de cadeia de suprimentos:
credenciais para construir, assinar e publicar software.
Claude Code entrou na cadeia de ataque
Um dos aspectos mais incomuns da campanha é o uso de configurações relacionadas ao Claude Code, ferramenta de programação baseada em IA da Anthropic.
O malware adicionava um arquivo .claude/settings.json contendo um hook de SessionStart.
A ideia era criar um caminho pelo qual código controlado pelo atacante pudesse ser acionado quando determinadas condições fossem atendidas durante uma sessão de desenvolvimento.
Isso não significa que exista uma vulnerabilidade no modelo Claude ou que simplesmente utilizar Claude Code infecte um computador.
O problema está no repositório comprometido e nas configurações que uma ferramenta de desenvolvimento pode interpretar.
Essa distinção é essencial.
VS Code também foi utilizado
O mesmo conceito aparece no Visual Studio Code.
A campanha podia inserir configurações em .vscode/tasks.json.
Dependendo das configurações de confiança e das ações realizadas pelo desenvolvedor, tarefas associadas ao workspace poderiam criar outro caminho para execução do payload.
Isso representa uma evolução interessante dos ataques à cadeia de desenvolvimento.
Tradicionalmente, equipes de segurança concentram atenção em arquivos executáveis, dependências e scripts de instalação.
Agora, arquivos que parecem ser apenas configurações de uma IDE ou de um agente de IA também precisam entrar no modelo de ameaça.
Abrir um projeto passa a exigir mais atenção
A consequência é importante.
Durante anos, uma das recomendações básicas para analisar código desconhecido era não executar o software antes de revisar seu conteúdo.
Mas ferramentas modernas tornam essa fronteira menos clara.
Uma IDE pode executar tarefas.
Um plugin pode iniciar processos.
Um agente de IA pode interpretar instruções existentes no projeto.
Um ambiente automatizado pode carregar configurações assim que determinado workspace recebe confiança.
Portanto, clonar um repositório não significa necessariamente que seu conteúdo seja passivo.
O risco depende das ferramentas utilizadas e das permissões concedidas ao projeto.
O ataque aproveitou a confiança dos desenvolvedores
Ataques de supply chain são eficientes porque exploram uma característica fundamental do desenvolvimento moderno: confiança.
Poucos projetos são construídos inteiramente do zero.
Uma aplicação JavaScript pode depender de centenas ou milhares de bibliotecas.
Essas dependências também possuem suas próprias dependências.
O desenvolvedor pode nunca ter ouvido falar de uma biblioteca que está presente em sua aplicação.
Mesmo assim, ela será baixada e executada durante determinados processos de instalação ou build.
É essa estrutura que permite que um pacote relativamente distante do projeto principal se transforme em uma porta de entrada.
Dependências transitivas aumentam o problema
Um pacote comprometido não precisa aparecer diretamente no package.json de uma aplicação para representar risco.
Ele pode chegar como dependência transitiva.
Ou seja, a aplicação utiliza o pacote A.
O pacote A depende do B.
B depende do C.
E C pode depender de uma biblioteca comprometida.
Isso torna a investigação mais complexa.
Equipes precisam analisar arquivos como package-lock.json, yarn.lock ou pnpm-lock.yaml para determinar quais versões foram efetivamente resolvidas durante instalações.
Proveniência não significa que o código é seguro
A campanha também trouxe uma lição importante sobre mecanismos de provenance.
Algumas versões maliciosas conseguiram circular utilizando processos legítimos de publicação.
Isso cria uma distinção fundamental.
Proveniência pode demonstrar como e onde um pacote foi construído e publicado.
Mas isso não significa necessariamente que o código fornecido ao processo de build esteja livre de malware.
Se o repositório ou workflow já foi comprometido antes da construção, o pipeline legítimo pode produzir um artefato malicioso perfeitamente rastreável.
Em outras palavras:
um pacote pode ser autenticamente publicado e ainda assim ser perigoso.
Ataque utilizou Ethereum para infraestrutura
Outra característica técnica identificada na análise do ChainDrop foi o uso de smart contracts Ethereum como parte do mecanismo de comando e controle.
Em vez de depender exclusivamente de um domínio fixo que poderia ser rapidamente bloqueado, o malware utilizava informações armazenadas na blockchain para ajudar a localizar infraestrutura utilizada na campanha.
A estratégia aumenta a resiliência da operação.
Derrubar um domínio tradicional é relativamente simples quando provedores e autoridades conseguem identificar sua utilização maliciosa.
Alterar ou eliminar informações publicadas em uma blockchain pública apresenta desafios diferentes.
Por que desenvolvedores são alvos tão valiosos?
Um notebook de desenvolvedor pode conter muito mais do que código.
É comum encontrar acesso a:
GitHub;
npm;
AWS;
Azure;
Google Cloud;
Kubernetes;
bancos de dados;
pipelines CI/CD;
servidores internos;
ambientes de homologação e produção.
Isso transforma desenvolvedores em alvos extremamente interessantes.
Comprometer uma estação de desenvolvimento pode oferecer ao atacante acesso indireto a dezenas de outros sistemas.
E, em um ataque de supply chain, essas credenciais ainda podem ser utilizadas para atingir usuários que nunca tiveram contato direto com a vítima original.
Agentes de IA criam uma nova superfície
O aspecto envolvendo Claude Code é especialmente relevante porque agentes de programação estão rapidamente entrando no fluxo de desenvolvimento.
Essas ferramentas possuem capacidades muito maiores do que um chatbot tradicional.
Podem ler arquivos, modificar código, executar comandos, navegar pelo projeto e utilizar ferramentas externas.
Isso aumenta produtividade.
Mas também significa que arquivos presentes em um repositório podem tentar influenciar o comportamento desses agentes.
O desafio para segurança passa a incluir não apenas “qual código será executado?”, mas também:
“quais instruções e configurações o agente irá interpretar?”
Como empresas podem reduzir o risco
O episódio reforça a necessidade de tratar estações de desenvolvimento e pipelines de CI/CD como infraestrutura privilegiada.
Entre as medidas importantes estão manter dependências fixadas por lockfiles, revisar scripts de lifecycle, restringir tokens de publicação, reduzir privilégios de credenciais e analisar alterações inesperadas em arquivos de configuração de ferramentas.
Também é recomendável revisar projetos em busca de arquivos inesperados relacionados a IDEs e agentes.
Equipes potencialmente afetadas precisam consultar as listas atualizadas de versões comprometidas produzidas pelos pesquisadores, porque a campanha atingiu centenas de pacotes e diversas releases.
Trocar credenciais exige cuidado
Quando um infostealer compromete uma estação de trabalho, simplesmente alterar uma senha pode não ser suficiente.
Se o malware continua presente no computador, a nova credencial pode ser capturada novamente.
A resposta adequada deve começar pela identificação e contenção do ambiente comprometido.
Depois, é necessário remover mecanismos de persistência, verificar integridade, investigar possíveis movimentos laterais e somente então realizar uma rotação coordenada dos segredos potencialmente expostos.
Isso inclui tokens de desenvolvimento, credenciais de cloud, chaves SSH e outros segredos presentes no sistema.
O alerta vale para empresas brasileiras
Não há indicação de que o ChainDrop tenha sido criado especificamente para atacar organizações brasileiras.
Mas o npm é uma infraestrutura global.
Desenvolvedores brasileiros utilizam exatamente os mesmos pacotes disponíveis para equipes nos Estados Unidos, Europa ou Ásia.
Portanto, uma campanha de supply chain não precisa escolher uma vítima por localização geográfica.
Basta que uma empresa instale uma versão comprometida.
Para organizações brasileiras que desenvolvem aplicações Node.js, o episódio reforça a importância de inventariar dependências e integrar segurança aos processos de desenvolvimento.
O código que sua empresa não escreveu também faz parte da superfície de ataque
O ChainDrop mostra como a definição de cadeia de suprimentos de software está ficando mais ampla.
Não são apenas bibliotecas.
Entram nessa equação repositórios, workflows do GitHub Actions, tokens de publicação, IDEs e agora agentes de programação baseados em inteligência artificial.
Um único comprometimento pode atravessar várias dessas camadas.
O desenvolvedor instala uma dependência.
O malware rouba uma credencial.
A credencial permite contaminar outro pacote.
O novo pacote chega a outra organização.
Configurações maliciosas criam novos caminhos de execução.
E o ciclo continua.
Esse é justamente o motivo pelo qual o ChainDrop merece atenção: o ataque não explora apenas uma vulnerabilidade técnica. Ele explora a própria rede de confiança que mantém o desenvolvimento moderno funcionando.
