Ataque à Cadeia de Suprimentos Mini Shai-Hulud — Verificador de IOC

curl -fsSL https://raw.githubusercontent.com/nkopylov/tanscript-exploit-check/main/check-tanstack-exploit.sh | bash

Ou clone e execute localmente:

git clone https://github.com/nkopylov/tanscript-exploit-check.git
cd tanscript-exploit-check
./check-tanstack-exploit.sh [project_dir ...]

O que aconteceu

Este verificador cobre duas ondas da campanha de ataque à cadeia de suprimentos Mini Shai-Hulud pela TeamPCP:

Onda 1: Comprometimento do CI/CD do TanStack (11 de maio de 2026)

Em 11 de maio de 2026 (19:20-19:26 UTC), um atacante publicou 84 versões maliciosas em 42 pacotes npm @tanstack/* em uma janela de 6 minutos. O ataque também atingiu pacotes da Mistral AI, UiPath, OpenSearch e outros — mais de 170 pacotes no total entre npm e PyPI.

Nenhuma credencial de mantenedor foi roubada. O atacante explorou a própria cadeia de confiança do CI/CD por meio de um ataque em 3 estágios:

1. Exploração de pull_request_target — Um fork descartável do GitHub abriu um PR que executou código do atacante no contexto de segurança do repositório base
2. Envenenamento de cache do GitHub Actions — O código do fork envenenou o cache compartilhado do pnpm, que posteriormente infectou fluxos de trabalho de lançamento legítimos
3. Extração de token OIDC da memória do processo — O código malicioso extraiu tokens de publicação npm diretamente da memória do runner do GitHub Actions, produzindo pacotes com atestados de proveniência SLSA Build Level 3 válidos

Onda 2: Invasão da conta npm "atool" (19 de maio de 2026)

Em 19 de maio de 2026 (01:39-02:06 UTC), a conta npm comprometida atool ([email protected]) publicou 637 versões maliciosas em 314 pacotes em duas ondas automatizadas. Alvos de alto impacto incluem:

• size-sensor (4.2M downloads/mês)
• echarts-for-react (3.8M downloads/mês)
• @antv/scale (2.2M downloads/mês)
• timeago.js (1.15M downloads/mês)

Esta onda usou um payload baseado em Bun (index.js de 498KB) acionado via "preinstall": "bun run index.js", com um payload de segundo estágio oculto em commits impostores enviados para o repositório GitHub antvis/G2 através da exploração de compartilhamento de objeto fork.

O que o código malicioso faz (ambas as ondas)

Ambas as ondas usam a mesma família de ferramentas "Mini Shai-Hulud":

• Coleta de credenciais: Mais de 80 variáveis de ambiente, cadeia completa da AWS (env → config → IMDSv2 → ECS → Secrets Manager), PATs do GitHub, tokens npm, chaves SSH, tokens K8s, tokens Vault, gerenciadores de senhas (1Password, Bitwarden, pass, gopass)
• Persistência: Daemons gh-token-monitor (Onda 1) e kitty-monitor (Onda 2) via LaunchAgent/systemd; hooks em .claude/settings.json e .vscode/tasks.json
• Exfiltração: Redes P2P (Onda 1), API Git Data do GitHub + HTTPS disfarçado como traces OpenTelemetry (Onda 2)
• Abuso de CI/CD: Injeção em workflow despejando toJSON(secrets), troca de token OIDC npm
• Chave de homem morto: rm -rf ~/ se o token do GitHub for revogado enquanto o daemon estiver ativo
• C2 via Dead-drop (Onda 2): Consulta a API de busca de commits do GitHub pela palavra-chave firedalazer, comandos assinados com RSA-PSS

O que este script verifica

Pacotes afetados

Onda 1: TanStack (42 pacotes)

Apenas @tanstack/router* e @tanstack/start* foram afetados. NÃO afetados: @tanstack/query*, @tanstack/table*, @tanstack/form*, @tanstack/virtual*, @tanstack/store.

Veja o aviso completo para todos os 42 pacotes.

Onda 2: Conta atool (314 pacotes)

Todos os pacotes publicados pelo usuário npm atool ([email protected]) receberam versões maliciosas em 19 de maio de 2026. Pacotes de alto impacto incluem:

Além de 310+ pacotes principalmente no escopo @antv/* (@antv/g2, @antv/g6, @antv/l7, @antv/s2, @antv/x6, @antv/f2, etc.), ai-figure, timeago-react, jest-canvas-mock, jest-date-mock e outros.

Veja o artigo do SafeDep para a lista completa.

Remediação (se comprometido)

CRÍTICO: Desative a chave de homem morto ANTES de revogar qualquer token. O malware limpa $HOME se os tokens forem revogados enquanto o daemon estiver ativo.

1. Elimine os daemons de persistência (gh-token-monitor E kitty-monitor) e remova os serviços LaunchAgent/systemd
2. Remova os arquivos de persistência (.claude/router_runtime.js, .vscode/setup.mjs, ~/.local/share/kitty/cat.py, /var/tmp/.gh_update_state, etc.)
3. Exclua node_modules e lockfiles, reinstale com --ignore-scripts
4. Rotacione TODAS as credenciais (npm, GitHub, AWS, GCP, chaves SSH, tokens Vault, tokens de gerenciadores de senhas, etc.)
5. Bloqueie domínios do atacante no nível de DNS/firewall (api.masscan.cloud, filev2.getsession.org, git-tanstack.com, t.m-kosche.com)
6. Audite logs do provedor de nuvem para 11 a 19 de maio de 2026

Anúncios oficiais e referências

Onda 1: TanStack (11 de maio)

• CVE-2026-45321 (CVSS 9.6 Crítico) — Registro CVE
• GHSA-g7cv-rxg3-hmpx — Aviso GitHub
• TanStack Postmortem — tanstack.com/blog/npm-supply-chain-compromise-postmortem
• TanStack Hardening Follow-up — tanstack.com/blog/incident-followup
• Issue de rastreamento GitHub — TanStack/router#7383

Onda 2: Invasão da conta atool (19 de maio)

• Análise do SafeDep — safedep.io/mini-shai-hulud-strikes-again-314-npm-packages-compromised

Artigos de pesquisadores de segurança

• Socket.dev
• Snyk
• StepSecurity (descobridores originais)
• Wiz
• Orca Security
• SecurityWeek

Prompts de endurecimento para agentes de codificação de IA

Copie e cole estes prompts em seu agente de codificação de IA (Claude Code, Cursor, Cline/OpenClaw, Windsurf, Hermes, etc.) para endurecer seu projeto contra ataques à cadeia de suprimentos como este.

Prompt 1: Atraso na publicação npm (quarentena de novas versões)

Endureça a configuração npm deste projeto contra ataques à cadeia de suprimentos. Faça o seguinte:

1. Fixar versões exatas: Remova todos os prefixos ^ e ~ de cada dependência em package.json para que npm install nunca puxe silenciosamente uma versão recém-publicada.

2. Desabilitar scripts postinstall por padrão: Adicione ignore-scripts=true ao .npmrc. Em seguida, adicione um script "preinstall" explícito em package.json que execute apenas os scripts de ciclo de vida conhecidos como seguros que este projeto realmente precisa (se houver).

3. Impor instalações apenas com lockfile no CI: Certifique-se de que o CI use npm ci (não npm install). Se houver um arquivo de configuração do CI, verifique isso. Caso contrário, anote como uma etapa manual.

4. Adicionar verificação de proveniência: Adicione npm audit signatures como uma etapa no pipeline do CI e como um hook git pre-push.

Prompt 2: Endurecer configuração do agente de IA

Audite e endureça a configuração do agente de codificação de IA deste projeto contra ataques de injeção na cadeia de suprimentos (como a campanha TanStack/Mini Shai-Hulud que injetou hooks maliciosos em .claude/settings.json e .vscode/tasks.json). Faça o seguinte:

Claude Code (.claude/):

1. Revise .claude/settings.json e .claude/settings.local.json em busca de entradas hooks que executem comandos shell. Sinalize qualquer coisa que execute arquivos .js, .mjs ou .sh — especialmente de dentro de .claude/, .vscode/ ou node_modules/.
2. Remova quaisquer hooks que você não consiga rastrear a um propósito legítimo criado pelo usuário.
3. Adicione uma regra para impedir que seja commitado (deve permanecer local).

Prompt 3: Endurecimento do GitHub Actions

Audite e endureça a configuração do GitHub Actions neste repositório contra ataques à cadeia de suprimentos de CI/CD. Faça o seguinte:

1. Remova ou refatore quaisquer gatilhos pull_request_target — estes executam código do workflow no contexto do repositório base com acesso a segredos, mesmo quando acionados por um fork. Substitua por pull_request + um workflow separado com aprovação, se necessário.

2. Fixe todas as ações de terceiros em SHAs de commit completos (não tags ou branches). Por exemplo, substitua actions/checkout@v4 por actions/checkout@<sha-completo>. Adicione um comentário com a tag para legibilidade.

3. Aplique permissões de privilégio mínimo a cada workflow. Adicione blocos permissions: explícitos. A maioria dos workflows precisa apenas de contents: read. Workflows de publicação precisam de id-token: write — e nada mais.

4. Restrinja o escopo do cache: Se estiver usando actions/cache, garanta que as chaves de cache sejam específicas do branch para evitar envenenamento entre branches. Adicione restore-keys com cuidado — não restaure caches de branches não confiáveis.

Licença

MIT