Worm de npm armou 42 repositórios no GitHub com ganchos para Claude

Um worm que se espalha por pacotes do npm, o maior repositório de bibliotecas JavaScript, deixou de ser só um teste. A equipe de pesquisa de segurança da JFrog publicou na segunda-feira (26) um relatório dizendo que o operador da campanha chamada testmetest já tinha armado 42 repositórios reais do GitHub, pertencentes a 11 donos legítimos, entre desenvolvedores individuais e organizações. Os repositórios continham ganchos de execução para assistentes de código com IA e editores, como Claude, Gemini, Cursor e VS Code. O detalhe técnico está no relatório da JFrog, de 26 de outubro de 2026.

A descoberta muda o que se sabia até então. Na semana anterior, a empresa de segurança de cadeia de suprimentos SafeDep tinha identificado a campanha e concluído, em 22 de outubro, que ela não tinha vítimas confirmadas: toda a atividade parecia vir de contas de teste do próprio atacante. A JFrog chegou à conclusão oposta olhando para o outro lado da operação, a infraestrutura no GitHub.

O que a JFrog encontrou

Segundo o relatório, os 42 repositórios armados tinham arquivos de configuração que fazem assistentes de IA e editores executarem código ao abrir a pasta do projeto: .claude/settings.json, .gemini/settings.json, .cursor/mcp.json, .cursor/rules/setup.mdc e .vscode/tasks.json. Junto deles ficava um arquivo .github/init.js com um embrulho polimórfico de 12,9 a 13,7 MB, que, depois de decodificado, revela sempre a mesma carga: um "publicador" que roda dentro do GitHub Actions, rouba tokens e tenta publicar versões maliciosas de pacotes no npm.

O tamanho enorme dos arquivos não é acidental. A JFrog explica que a busca de código do GitHub não indexa blobs desse porte e que a API de conteúdo não consegue devolvê-los. Na primeira varredura, os pesquisadores acharam os ganchos em 26 repositórios e concluíram, por engano, que os arquivos de carga estavam vazios. Só ao listar cada repositório pela API de árvores e blobs do Git ficou claro que todos estavam armados, e a varredura completa das contas elevou o total para 42.

Como a campanha funciona

O ponto de partida são pacotes do npm com nomes inocentes, a maioria terminando em -testmetest. Eles usam um truque no arquivo binding.gyp para executar código durante a instalação, mesmo sem declarar um script de instalação convencional. A carga rouba credenciais do GitHub e do npm, altera repositórios e configurações de integração contínua e se propaga por outros pacotes. Segundo a cobertura do The Register, o malware também instala um limpador que apaga a pasta pessoal da vítima caso o token roubado seja revogado, característica herdada de variantes anteriores da família Shai-Hulud.

Uma novidade apontada no relatório é o disfarce em um addon nativo compilado. Três pacotes trazem um arquivo binário que não contém carga alguma e, ao ser instalado, decifra um arquivo escondido chamado .napi_cache para revelar o código real. Antes de agir, esse addon confere se está em um servidor de integração contínua, contêiner, máquina virtual pequena ou sob depurador, e nesses casos não faz nada. O efeito prático é disparar em notebooks e servidores de pessoas de verdade e ficar quieto dentro dos ambientes que os scanners automáticos usam. A JFrog também registra que a versão para Windows ainda procura ferramentas de análise como Wireshark e Process Monitor.

No lado do GitHub, a conta do atacante hospeda 17 repositórios da campanha. Alguns têm ramos de vida curta com um arquivo ci.js e um fluxo de trabalho que obtém um token de identidade do GitHub Actions, troca por um token de publicação do npm e tenta publicar uma versão adulterada do pacote-alvo. Um repositório isca virou depósito de dados: até 25 de outubro, tinha 27 arquivos de captura, num total de 384.825 bytes, com conteúdo que parece um envelope criptografado. A JFrog não decifrou nada e avisa que não dá para saber quantos sistemas foram afetados.

Tokens reais vazados por um falso CodeQL

Alguns ramos tinham um fluxo de trabalho chamado CodeQL, nome de uma ferramenta legítima de análise de código, que na verdade despejava as variáveis de ambiente, incluindo o NPM_TOKEN, num artefato de um dia de vida. A JFrog conseguiu capturar 29 desses artefatos antes de expirarem e encontrou três tokens de acesso do npm em formato real, alternados entre seis repositórios. Os valores foram tratados como comprometidos e não foram reproduzidos. A empresa também ressalta o que não está provado: não há evidência de uma cadeia contínua ligando cada infecção do npm ao uso de uma falha em cPanel e WHM (CVE-2026-41940) que aparece em artefatos do mesmo grupo de contas sequestradas, e nenhum comprometimento posterior de cPanel foi confirmado.

O relatório também alerta contra exagero em outro ponto. Uma versão do worm foi publicada em 21 de outubro sem que nenhuma execução registrada do GitHub Actions coincidisse com o horário, então ela provavelmente foi enviada à mão com um token ou por uma execução apagada depois. O código recuperado mostra o mecanismo planejado, não que cada publicação tenha usado essa automação.

O que isso muda para quem usa IA no código

O recado central é que os arquivos de configuração de assistentes de IA entraram na lista de lugares onde um atacante esconde código. Ferramentas como Claude Code, Gemini CLI e Cursor leem configurações do próprio projeto, e algumas delas podem executar comandos ou iniciar servidores MCP a partir dessas pastas. Isso é conveniente para equipes, e é também a razão de um repositório clonado de origem duvidosa poder disparar algo antes de você ler uma linha do código.

A JFrog não afirma que Claude, Gemini ou Cursor tenham falha própria: os ganchos usam recursos legítimos de configuração. O risco está no hábito de abrir e confiar em projetos sem conferir. O relatório inclui os nomes dos pacotes e indicadores de comprometimento; quem instalou algum pacote com o sufixo testmetest ou os três pacotes de addon nativo deve tratar a máquina como comprometida, trocar todos os tokens e procurar arquivos ocultos em /tmp (no Linux) ou na pasta temporária do usuário (no Windows).

Por que isso importa para você

Se você usa assistentes de código para criar sites, automações ou agentes e vive de entregar isso a clientes, uma conta do GitHub ou do npm sequestrada é um prejuízo direto: seus repositórios podem publicar malware em seu nome. Algumas medidas simples reduzem o risco: ative autenticação em dois fatores com chave de acesso, use tokens com prazo curto e permissões mínimas, e desconfie de repositórios que trazem pastas como .claude, .cursor ou .vscode sem explicação. Antes de abrir um projeto de terceiros num assistente, veja o conteúdo desses arquivos e as tarefas configuradas.

O Portal da AI já acompanhou outros golpes na mesma linha: o pós-mortem do ataque à LiteLLM, que começou numa chave mestra exposta, a versão comprometida do LiteLLM que roubava credenciais de IA, a falha Plugin4Shell em agentes de código e o 1Password for Agents, que tenta guardar segredos longe do alcance dos agentes. Para se proteger no dia a dia, veja o checklist para escolher uma ferramenta de IA com segurança, o guia de gerenciador de senhas e o de chaves de acesso (passkey).

Vale lembrar que a análise é de uma empresa de segurança com interesse comercial no tema e que a investigação segue aberta: o número de repositórios e donos afetados pode crescer, como já aconteceu entre a primeira e a segunda varredura.