ChainDrop: proveniência válida em mais de 400 pacotes npm, e hooks do Claude Code que não exigem npm install

Em 4 de agosto de 2026 atacantes assumiram o controle da conta do GitHub por trás da keyv, uma biblioteca de cache que, segundo o Elastic Security Labs, foi baixada mais de 600 milhões de vezes no mês anterior. A Wiz Research e a Orca Security registram que arquivos maliciosos foram enviados diretamente para o branch principal do keyv, e que o workflow do GitHub Actions do próprio projeto então compilou e publicou a versão envenenada — de modo que ela chegou ao npm carregando proveniência válida, que a ferramenta de atestação da cadeia de suprimentos usa para decidir se um pacote é confiável. Um worm autorreplicante que os pesquisadores chamam de ChainDrop então usou tokens npm roubados para repetir o truque nos pacotes de outros mantenedores: a Elastic contou mais de 400 pacotes exclusivos até 6 de agosto, a Microsoft Threat Intelligence descreveu a mesma campanha em 4 de agosto, e a Cyber Security Agency de Singapura contou mais de 1.300 versões de pacotes comprometidas com um total combinado de 2 bilhões de downloads mensais. A Elastic e a Microsoft descrevem ambas hooks que são executados novamente quando um repositório é aberto no Claude Code ou no Visual Studio Code. A lista completa de fontes do registro, a classificação de gravidade e a avaliação de confiança estão em o arquivo de incidentes de IA, junto com as outras entradas de cadeia de suprimentos de npm e de ferramentas de desenvolvimento registradas em torno dele.

Como um pipeline de lançamento legítimo assinou seu próprio comprometimento

A Wiz Research reconstrói os minutos iniciais: a partir das 09:00 UTC de 4 de agosto o atacante usou uma identidade comprometida para introduzir payloads de persistência de IDE no repositório keyv e, logo em seguida, publicou uma nova versão do keyv contendo o payload. A Wiz identifica a parte comprometida como uma conta de mantenedor do GitHub e afirma que vários pacotes do ecossistema keyv e cacheable se seguiram.

O relatório de resposta rápida da Orca Security é mais específico sobre o caminho de assinatura. Segundo ele, o atacante enviou dois arquivos maliciosos — setup.mjs e Math_Symbol.js — diretamente para a branch principal e imediatamente lançou novas versões. Como essas versões foram criadas por meio dos workflows do GitHub Actions da conta comprometida, as versões envenenadas foram publicadas no npm com assinaturas de proveniência válidas, contornando as verificações padrão de integridade da cadeia de suprimentos. A Zscaler ThreatLabz, uma equipe de pesquisa independente que não está entre as fontes citadas no registro, chega à mesma conclusão e atribui um nível a isso: o malicioso keyv 6.0.0 carregava proveniência válida SLSA Build Level 3 porque o atacante controlava o repositório de origem. O BleepingComputer, que relatou a campanha no dia, registra o mesmo mecanismo — arquivos maliciosos enviados diretamente para as branches principais dos projetos, novas versões geradas, proveniência válida porque as builds foram executadas por meio de workflows legítimos do GitHub Actions.

A análise da Microsoft acrescenta um detalhe que parece uma contradição e não é. Na fase de propagação do worm, a Microsoft Threat Intelligence descobriu que muitas versões maliciosas não tinham nenhum commit de código-fonte, pull request, tag ou lançamento legítimo correspondente, o que indicava que os atacantes modificaram e publicaram tarballs de pacotes diretamente, em vez de comprometer cada repositório público de código-fonte. Lidas em conjunto, as fontes descrevem dois regimes de assinatura dentro de uma mesma campanha: as primeiras versões do keyv passaram pelo pipeline de CI real da vítima e carregam atestações que comprovam isso, enquanto as versões posteriores do worm foram em grande parte montadas e publicadas com tokens de registro roubados, não deixando nenhum rastro de código-fonte. A própria observação da Microsoft é que o padrão de tarball direto explica por que lançamentos maliciosos frequentemente apareciam como um incremento normal da versão de patch sem commits de código-fonte ou pull requests correspondentes.

A lição incômoda é enunciada claramente pela Zscaler: a proveniência valida o processo de build, não a identidade da conta nem a integridade do sistema de CI que o executa. A empresa também admite uma lacuna relevante para quem quer que tente reconstruir o incidente — o mecanismo exato de tomada de conta usado pelo atacante era desconhecido no momento da sua análise.

O que roda no npm install: preinstall, Bun 1.3.13 e um coletor de 300 padrões

O Elastic Security Labs descreve o gatilho como um preinstall hook no package.json, que abusa de um recurso legítimo do npm que executa comandos arbitrários antes de um pacote concluir a instalação, sem exigir mais interação da vítima. O hook inicia setup.mjs, que verifica se o runtime JavaScript Bun já está presente. Se não estiver, o dropper detecta a plataforma e a arquitetura da máquina, baixa Bun v1.3.13 da página oficial de lançamentos, extrai-o, usa-o para executar o payload e depois exclui o diretório temporário para apagar seus rastros. A Wiz identificou independentemente o user agent Bun/1.3.13 fazendo as chamadas maliciosas. O dropper é multiplataforma, voltado para Linux, macOS e Windows.

O payload é fortemente ofuscado, e as fontes divergem ligeiramente quanto ao seu tamanho: a Elastic o situa em 711 kilobytes, e a Orca Security em 728 KB. Ele utiliza achatamento de fluxo de controle (control-flow flattening) e um esquema de codificação de strings em Base91, e carrega strings com temática de Dune — laza, kanly, ghola, mentat, lasgun, sietch, fedaykin, tleilaxu, sandworm, sardaukar, ornithopter, navigator — o que, conforme observa a Elastic, apresenta semelhanças com campanhas anteriores do Shai-Hulud.

O relato comportamental da Microsoft acrescenta dois detalhes que vale a pena conhecer. O payload verifica primeiro seu ambiente e sai em sistemas com idioma russo, evita instâncias duplicadas e inicia uma cópia desanexada em segundo plano nas estações de trabalho dos desenvolvedores; dentro do CI, permanece vinculado ao job ativo para poder alcançar segredos do fluxo de trabalho, credenciais do runner e permissões de publicação do OpenID Connect.

O coletor é onde o incidente se torna um caso de ferramentas de IA, e não um caso genérico de credenciais. A Elastic afirma que ele varre mais de 300 padrões exclusivos em armazenamentos de credenciais em uma máquina de desenvolvedor, e que o direcionamento notável tem como alvo credenciais de ferramentas de IA: Anthropic, Claude, Codex, Cursor, OpenAI e Gemini. Também coleta credenciais AWS, GCP, Azure e Alibaba Cloud, tokens de acesso pessoal do GitHub, tokens JWT e de sessão, tokens do HashiCorp Vault, chaves privadas SSH, tokens de conta de serviço do Kubernetes e tokens npm. A Wiz relata que a lista de alvos foi ampliada em quase 70% em relação ao código anterior do Mini Shai-Hulud no qual ele se baseia, com novos acréscimos, incluindo armazenamentos de credenciais de agentes de IA para Claude, OpenAI, Codex, Cursor e Gemini, keystores de criptomoedas para Foundry, Solana e Monero, master.key do Jenkins, segredos do Argo CD e do Harbor, configurações de CLI da Alibaba e da Tencent, e /etc/shadow.

Tanto a Microsoft quanto a Elastic descrevem o mesmo design de exfiltração. Os resultados são serializados como JSON, compactados com gzip e criptografados com uma chave AES-256-GCM gerada aleatoriamente, e essa chave é envolvida com a chave pública RSA do atacante. O payload não codifica permanentemente seu domínio de comando e controle: a Elastic afirma que ele consulta um contrato inteligente Ethereum em 0xE1f2395ee43e45A1556EC6438a88c31B83493103 para buscar o endpoint atual em tempo de execução, de modo que a infraestrutura possa ser rotacionada sem modificar o malware. Se isso falhar, ele procura um marcador assinado criptograficamente — thebeautifulmarchoftime — no histórico de commits do GitHub e valida o domínio com uma chave RSA incorporada. Se ambos falharem, ele exfiltra por meio de um repositório público do GitHub criado pela própria conta da vítima, descrito como "Shai-Hulud: Here We Go Again". A Microsoft observa que um caminho alternativo codifica um token roubado do GitHub com Base64 duplo em vez de criptografá-lo.

A propagação depende da qualidade do token. A Elastic relata que o worm só é ativado quando a varredura de credenciais encontra um token npm com permissão de escrita em pacotes e a capacidade de publicar sem autenticação de dois fatores; ele então baixa o tarball mais recente de cada pacote gravável, injeta a si mesmo, aumenta a versão de patch e republica. A BleepingComputer acrescenta que cada token é validado em tempo real no endpoint whoami do registro antes de ser roubado. Essa rotina foi o que transformou uma identidade comprometida em centenas de lançamentos, e é por isso que as versões maliciosas parecem aumentos comuns de versão de patch.

O caminho de infecção que não precisa de npm install

A descoberta que separa esta campanha dos vermes npm anteriores é que a instalação não é mais a única forma de entrada. A Elastic descreve dois caminhos adicionais de execução voltados aos usuários de ferramentas de codificação com IA. Um hook SessionStart em .claude/settings.json executa node .claude/setup.mjs quando uma nova sessão do Claude é iniciada. Para o VS Code, uma tarefa folderOpen em .vscode/tasks.json executa node .vscode/setup.mjs quando um repositório infectado é aberto. A análise da Microsoft lista os mesmos quatro artefatos — .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json e .vscode/setup.mjs — e os descreve como uma rota secundária de infecção que pode reiniciar o payload depois que a instalação npm original foi concluída.

A condição que amplia isso drasticamente está nas credenciais roubadas. Quando um token do GitHub App está entre elas, a Elastic relata que o worm faz commit dos hooks maliciosos em até 50 branches por repositório acessível, injetando .claude/settings.json e .vscode/tasks.json em cada uma. A conclusão da Elastic é que um desenvolvedor que clona uma dessas branches e a abre pode ser infectado ao abrir o projeto — sem instalação de pacotes e, portanto, sem qualquer defesa por script de instalação no caminho.

A avaliação da Zscaler é que os ganchos de persistência sobrevivem à remoção do pacote e são reexecutados simplesmente ao abrir o projeto no VS Code ou no Claude Code, o que contorna a mitigação conhecida como --ignore-scripts que muitas equipes adotaram após vermes npm anteriores. Sua recomendação decorre diretamente: tratar arquivos de configuração de IDE e de agentes de IA — .claude/, .cursor/, .vscode/, .gemini/ — como código executável, revisados com o mesmo rigor que o código-fonte.

Há uma impressão digital para a metade do ataque relacionada ao repositório. A Elastic relata que commits gerados pelo worm podem ser identificados pelo nome do autor claude e pela mensagem de commit chore: update config, e a Wiz registra a mesma string de mensagem. A Elastic acrescenta que a mensagem de commit também continha o token do GitHub roubado, junto com uma string de intimidação — IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClients — que ela interpreta como uma tentativa de assustar os desenvolvedores para que não revoguem o token. A Wiz registra a mesma string nos commits iniciais, com a mensagem mais curta substituída nos commits que introduzem os hooks da IDE.

As contagens não coincidem, e isso não é uma contradição

Todos os números publicados sobre o raio de alcance estão associados a uma unidade diferente, e as unidades não são intercambiáveis. O Elastic Security Labs, em texto de 6 de agosto, contou mais de 400 pacotes npm únicos comprometidos. A Microsoft Threat Intelligence descreveu mais de 400 pacotes em vários editores não relacionados. A Aikido, citada pelo BleepingComputer, indicou pelo menos 868 pacotes em 1.381 versões. A Orca Security relata 10 pacotes keyv e cacheable diretamente envenenados, com mais de 619 milhões de downloads mensais, e depois 868 pacotes adicionais e 1.381 versões alcançados pelo worm, somando mais de 2 bilhões de instalações mensais. O aviso AD-2026-009 da CSA de Singapura, datado de 6 de agosto, registra mais de 1.300 versões de pacotes comprometidas que representam um total combinado de 2 bilhões de downloads mensais.

Esses são três denominadores diferentes — pacotes, versões de pacotes e volume mensal de downloads — registrados em três momentos diferentes de uma campanha que ainda estava em andamento. O relato da Zscaler sobre a velocidade explica por que eles divergem: ele diz que o worm se propagou automaticamente para mais de 400 pacotes em menos de quatro horas e, no pico, publicava aproximadamente um pacote infectado por segundo. Tratar uma contagem posterior como uma correção de uma anterior estaria errado; cada uma é um instantâneo, e nenhuma das fontes citadas afirma um total final.

Os números de exposição da Elastic no nível da biblioteca são os mais frequentemente citados e os menos ambíguos. Ela informa que somente o keyv registrou mais de 600 milhões de downloads no mês anterior, com flat-cache perto de 580 milhões, cacheable-request acima de 137 milhões, cacheable acima de 30 milhões e cache-manager acima de 16 milhões. O comunicado do CSA lista as versões específicas comprometidas, entre elas keyv 6.0.0, flat-cache 6.1.24, file-entry-cache 11.1.6, cacheable-request 13.0.20, cacheable 2.5.1, cache-manager 7.2.10, @cacheable/utils 2.5.1 e ecto 5.0.1.

A armadilha da revogação

Os responsáveis pela resposta que instalaram uma versão afetada enfrentam um segundo problema depois do primeiro. A Elastic relata que, em um caminho alternativo condicional do GitHub, o payload tenta instalar um componente de monitoramento de token que mantém o acesso às credenciais e contém um manipulador destrutivo caso o token monitorado seja revogado. A Zscaler descreve o mecanismo em detalhes operacionais e o denomina armadilha de revogação de token: o worm instala um processo em segundo plano que consulta a API do GitHub a cada 60 segundos com o token roubado, e, se o token retornar um erro 4xx — o que significa que a vítima o revogou —, um payload destrutivo secundário é acionado, o qual, dependendo da variante, pode incluir execução remota de código ou exclusão do diretório inicial do usuário.

A Wiz acrescenta que o dead-man's switch é armado seletivamente com base em uma resposta do servidor de comando e controle: o operador pode retornar um valor que especifica qual comando armar e qual token o interruptor deve monitorar para revogação. A Wiz também observa que o monitor busca uma resposta válida do endpoint do usuário, portanto qualquer tipo de token válido ali pode servir como gatilho.

A consequência prática é registrada pelo BleepingComputer e pela orientação da Aikido que ele cita: uma estação de trabalho de desenvolvedor ou um runner de CI/CD que instalou uma versão afetada deve ser tratado como comprometido mesmo que o pacote tenha sido removido posteriormente, porque a execução de segundo estágio pode ter exposto tokens e comprometido a integridade da build. A orientação da Microsoft chega ao mesmo ponto pelo lado da build, alertando que as organizações que instalaram um pacote afetado com scripts de ciclo de vida habilitados devem tratar a estação de trabalho ou o runner de build como potencialmente comprometidos e reconstruir os sistemas afetados e os artefatos downstream a partir de fontes confiáveis.

O que está estabelecido, o que é avaliado e o que ninguém demonstrou

O registro primário e cinco análises independentes convergem quanto à mecânica, e as afirmações mecânicas são a parte mais forte do arquivo.

• A conta GitHub do mantenedor do keyv foi comprometida, e arquivos maliciosos foram enviados diretamente para a main antes de uma release ser publicada, em 4 de agosto de 2026 — relatado de forma consistente pela Wiz, pela Orca Security, pelo BleepingComputer e pela CSA Singapore.

• Pelo menos o keyv 6.0.0 chegou ao npm por meio do pipeline de CI da própria vítima, carregando proveniência válida, com a Zscaler especificando uma atestação SLSA Build Level 3. Esta é a alegação que torna o incidente notável, e é corroborada por três organizações que não foram coautoras do trabalho umas das outras.

• Um hook de pré-instalação executou setup.mjs, que baixou o Bun v1.3.13 e executou um payload ofuscado que verificou mais de 300 padrões de credenciais, incluindo credenciais de ferramentas de codificação com IA — Elastic e Wiz concordam tanto com a versão do runtime quanto com a lista de credenciais visadas por IA.

• Hooks gravados em .claude/settings.json e .vscode/tasks.json são executados na inicialização da sessão e ao abrir a pasta, e um token de GitHub App estendeu isso para até 50 branches por repositório acessível — a descoberta da Elastic, e a base de sua afirmação de que um desenvolvedor pode ser infectado ao abrir um repositório.

• Mais de 400 pacotes únicos foram comprometidos em poucos dias, e a CSA Singapore, órgão regulador nacional, publicou o aviso AD-2026-009 em 6 de agosto de 2026, listando as versões afetadas e os indicadores.

O que as fontes tratam como avaliação, e não como fato, deve ser rotulado como tal. A Wiz descreve o payload como descendente da família de malware Shai-Hulud "Mini", construído sobre repositórios públicos Shai-Hulud-Open-Source publicados pela TeamPCP, com algumas mudanças cruciais; a Orca Security atribui o ataque à TeamPCP; a Zscaler vincula o ChainDrop à TeamPCP e o situa em uma linhagem que remonta a setembro de 2025. Trata-se de um consenso de atribuição entre fornecedores, não de algo que um documento primário citado comprove sobre um indivíduo ou grupo nomeado.

Três coisas que nenhuma fonte citada estabelece, e que este artigo não preenche. Primeiro, como a conta do mantenedor foi comprometida: a Zscaler afirma claramente que o mecanismo exato era desconhecido no momento da sua análise. Segundo, um único total final: os números 400, 868 e 1.300 contam pacotes, pacotes-e-versões e versões em momentos diferentes, e nenhuma fonte afirma que a campanha esteja encerrada. Terceiro, e o mais importante para a alegação específica de IA neste registro, nenhuma fonte citada relata um caso confirmado de uma credencial roubada da Anthropic, Codex, Cursor, Gemini ou OpenAI sendo reutilizada contra uma conta de provedor. O que está documentado é intenção e capacidade — uma lista explícita de alvos e um coletor criado para alcançá-la — não uma violação comprovada a jusante dos sistemas de um provedor de IA.

O que mudou depois — e o que um socorrista tem de fazer

O remédio mais concreto no registro é uma mudança de plataforma. A Elastic recomenda atualizar paranpm 12 ou posterior, que bloqueia ganchos de preinstall por padrão; a orientação da Microsoft recomenda, de forma independente, o npm CLI v12 e o recursomin-release-age, que seguram as novas versões por tempo suficiente para a comunidade detectar um comprometimento antes que ele chegue a um build.

Além disso, as etapas de resposta que as fontes publicam se sobrepõem significativamente.

• Elastic: revogar todos os tokens do GitHub, incluindo tokens de sessão nas máquinas afetadas; revogar e regenerar tokens npm, especialmente tokens de automação com permissão de escrita e contorno de autenticação de dois fatores; pesquisar nos repositórios commits não autorizados com a mensagem chore: update config from claude@users.noreply.github.com; rotacionar segredos de nuvem, Kubernetes, Vault, ferramentas de IA e CI/CD; ativar autenticação de dois fatores nas contas npm.

• Microsoft: limpe os caches do npm e do yarn nos endpoints e hosts de build afetados, fixe versões comprovadamente boas, revise lockfiles e artefatos em busca das versões comprometidas, incluindo referências transitivas, reconstrua imagens base compartilhadas e runners de build de referência e revise escopos de token, aprovações de workflow e proveniência de release, porque o incidente é consistente com abuso de pipeline de CI/CD por meio de publicação OIDC.

• CSA Singapore: remova as versões afetadas dos ambientes de desenvolvimento, build e CI/CD, trate os sistemas afetados como comprometidos e reconstrua-os, faça rotação de credenciais, revise os ambientes de nuvem e de código-fonte em busca de acesso não autorizado, monitore indicadores publicados e fortaleça controles de allowlisting, verificação de integridade e proveniência.

• Zscaler: trate .claude/, .cursor/, .vscode/ e .gemini/ como código executável e pare de tratar a proveniência do SLSA ou do Sigstore como prova de segurança — combinando-a, em vez disso, com deteção de anomalias no comportamento de publicação, como publicações fora do horário de expediente, publicação de versões em massa e publicadores de primeira vez.

O registo não contém um resultado de remediação. Nenhuma fonte citada relata a remoção completa das versões maliciosas, a recuperação de uma conta, uma detenção ou uma ação de execução regulatória; o aviso da CSA é uma notificação aos defensores, não uma conclusão contra uma parte.

O que o incidente muda é uma classificação. Um arquivo de configuração de ferramenta de desenvolvimento é um caminho de execução, e um editor abrir uma pasta é um evento de execução. E uma atestação de proveniência é uma declaração sobre qual pipeline produziu um pacote — não sobre quem detinha as chaves quando esse pipeline foi executado, que é precisamente a lacuna pela qual o primeiro lançamento do keyv passou.