O ataque Shai-Hulud: por que apertar 'Sim' no Claude Code virou a nova falha crítica

Aquele um segundo antes de apertar “Sim”. Esse único segundo é a defesa mais confiável contra os 796 pacotes comprometidos na onda Shai-Hulud 2.0 de novembro de 2025, e contra as ondas que vieram depois em 2026. E continuam vindo.

Quem trabalha com Claude Code todo dia sabe do que estou falando. O prompt aparece:

Claude wants to run: npm install some-package
Allow? [Y/n]

E você aperta Y. Sem ler. Porque ler cada um cansa, porque você tá no flow, porque na maioria das vezes é seguro. Esse automatismo é exatamente o que o Shai-Hulud explora, e é por isso que 2026 já teve cerca de meia dúzia de ondas do mesmo worm com nomes diferentes.

Este post é o que aprendi olhando os postmortems públicos das ondas e reescrevendo minhas próprias regras. Não é ficção. Números e datas vêm dos relatórios que linko no fim.

A cronologia curta que dói

Em setembro de 2025, ReversingLabs e JFrog publicaram os primeiros relatórios sobre um worm chamado Shai-Hulud, que comprometeu cerca de 500 pacotes npm em sua primeira onda (incluindo @ctrl/tinycolor). Em novembro, uma segunda onda batizada Shai-Hulud 2.0 chegou a 796 pacotes npm comprometidos. Nome tirado dos vermes gigantes de Duna, e a analogia é boa: o bicho fica quieto embaixo da areia, sente a vibração de npm install, e engole o sistema.

Aí vieram as ondas seguintes, cada uma pior que a anterior:

Data	Campanha	Escopo	Fonte
Set 15, 2025	Shai-Hulud (onda 1, @ctrl/tinycolor)	~500 pacotes npm	Palo Alto Unit 42 / StepSecurity
Nov 24, 2025	Shai-Hulud 2.0	796 pacotes (1.092 versões)	Datadog Security Labs
Abr 23, 2026	Shai-Hulud: The Third Coming	Backdoor no @bitwarden/cli 2026.4.0 com prompt-injection contra agentes de IA	OX Security / Endor Labs
Abr 29, 2026	Mini Shai-Hulud (SAP CAP)	4 pacotes SAP em janela de ~4h (09:55-14 UTC)	Sophos / Onapsis
Mai 11, 2026	Nova onda TeamPCP	172 pacotes / 404 versões maliciosas (TanStack, Mistral AI, UiPath, OpenSearch)	Snyk / Akamai
Jun 1, 2026	Miasma (@redhat-cloud-services)	30+ pacotes via CI/CD comprometido	Wiz / Microsoft
Jul 14, 2026	AsyncAPI	4 pacotes (5 versões) via release pipeline	Microsoft / Datadog
Ago 4, 2026	ChainDrop (variante)	Compromete o mantenedor do keyv, backdoor em pacotes com 1,3 bilhão de downloads/mês	Elastic Security Labs

O detalhe que faz seu estômago doer: na variante ChainDrop de agosto, os pacotes atingidos (keyv, cacheable, flat-cache, file-entry-cache) somam mais de 1,3 bilhão de downloads mensais. Ou seja, se você trabalha com Node em 2026, muito provavelmente já baixou uma versão comprometida em algum momento. Pode não ter sido explorada no seu ambiente, mas você passou perto.

Por que o agente autônomo é o multiplicador

Sem Claude Code, o Shai-Hulud precisa do descuido de um humano: você digita npm install typosquattingpackage e não percebe. Com Claude Code no automático, o mesmo erro escala:

1. Você pede: “adicione um cache layer”
2. Claude sugere: npm install some-cache-lib
3. Você aperta Y (ou está com --dangerously-skip-permissions ligado)
4. O pacote é comprometido. Malware executa no postinstall
5. Suas chaves npm são exfiltradas
6. O malware usa suas chaves para republicar seus próprios pacotes contaminados
7. Seu ambiente vira o próximo elo da cadeia de propagação

Um agente autônomo aprovando comandos em sequência executa em 30 segundos o que um invasor humano manual levaria uma semana pra tentar. É por isso que, na leitura da Elastic Security Labs sobre o ChainDrop, a menção a “worm que usa credenciais roubadas para backdoor em pacotes co-mantidos” é o coração da coisa. A vítima vira atacante, sem intervenção humana.

As credenciais que o Shai-Hulud tá procurando

Dá pra ser específico. As variantes de 2026 miram:

• Tokens npm (para republicar como você)
• Tokens GitHub (para acessar repos privados)
• Chaves AWS / GCP / Azure / Alibaba
• Chaves SSH privadas
• Tokens de service account do Kubernetes
• Tokens HashiCorp Vault

Se algo disso tá na sua máquina em texto claro, e você usa Claude Code na mesma máquina com auto-approve, você tá exposto a uma classe inteira de ataques que não existia dois anos atrás.

Três camadas de defesa que funcionam

Fui aprendendo isso na base do susto. Compartilho porque o que vi em produção em times parceiros mostra que 90% das falhas acontecem na camada 1.

Camada 1: nunca ligar --dangerously-skip-permissions no diretório do dia a dia

O nome da flag é literal por um motivo. Ela existe para casos muito específicos (CI isolado, sandbox descartável, contêiner sem credenciais reais). Se você tá com o .npmrc do trabalho, chaves SSH pessoais e credenciais AWS na mesma máquina, não usa. Ponto.

Vi um dev usar isso no repo principal porque “ia rodar só 5 comandos”. No comando 3, Claude sugeriu um pacote de typosquat. Comando executado. Chaves comprometidas. Sorte que a resposta foi rápida.

Camada 2: CLAUDE.md com regra explícita antes de npm install

Regra simples no CLAUDE.md do projeto:

## Regras de instalação de pacotes

Antes de instalar qualquer pacote npm/pip/gem novo:
1. Reporte nome, autor e downloads semanais
2. Avise se downloads semanais < 1.000
3. Sinalize qualquer nome que pareça typosquat de um pacote popular
4. Nunca use --force ou --ignore-scripts sem confirmação explícita
5. Nunca instale pacotes cujo nome contenha "shai" ou "hulud"

A última linha é literal. O worm às vezes se autonomeia com esses prefixos. Serve como canário barato, sem pretensão de defesa completa.

Camada 3: monitoramento de ~/.npmrc e ~/.ssh/

Coloque esses caminhos em qualquer sistema de audit log que você já tenha. Se algo escreveu neles fora de uma janela em que você instalou algo intencionalmente, investiga. O ChainDrop, especificamente, enumera credenciais em várias localizações padrão e as encaminha via um esquema de dead-drop. Se o padrão bate, você sabe.

Nenhuma das três camadas isoladamente basta. Junto elas cobrem 90% dos cenários realistas. Os outros 10% são cadeia de suprimentos genuinamente sofisticada, e aí você depende do ecossistema (npm/GitHub) reagir rápido, que é o que aconteceu em cada onda de 2026.

O que eu mudei no meu fluxo

Três coisas concretas depois da onda de agosto:

1. Separo máquinas. Máquina onde uso Claude Code com liberdade não tem credenciais AWS de produção. As chaves reais moram numa segunda máquina que não roda agente autônomo nenhum.

2. Auto-approve só em sandbox/. Meu CLAUDE.md tem regra que só permite auto-approve dentro de subdiretórios chamados sandbox/ ou experiments/. Fora disso, cada npm install pede confirmação. Aceito o custo de digitar Y a mais vezes.

3. Reviso o /bug antes de mandar. Detalhe que me pegou no Zenn book: o comando /bug no Claude Code retém os dados por até 5 anos no plano consumer, independente da sua preferência de retenção padrão. Se você mandar um bug report com trecho de código sensível, ele fica lá. Copio, colo em outro editor, tiro o que for sensível, aí submeto.

Trust, but verify

Ronald Reagan usou uma frase nas negociações com Gorbachev: “trust, but verify”. Confio no Claude Code. Uso todo dia. Não escreveria metade dos meus projetos sem ele.

Mas confiança e fé cega são coisas diferentes.

Um segundo antes de apertar “Sim”. Nesse um segundo, você lê o nome do pacote, confere o comando, imagina o que ele vai fazer no seu sistema. Esse hábito de um segundo é a defesa mais confiável que existe contra o tipo de contaminação em cadeia que atingiu 1,3 bilhão de downloads mensais só em agosto.

O Shai-Hulud não vai embora. Vai mudar de nome, de vetor, de escopo. Vai voltar sob outro nome em outubro, dezembro, fevereiro do ano que vem. O que fica sob seu controle é aquele um segundo.

---

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews