O Incidente TanStack: Como Proteger seu Pipeline contra Ataques de Supply Chain
30/05/2026 - ⧖ 3 minTL;DR: Em maio de 2026, a TanStack sofreu um ataque sofisticado via GitHub Actions e OIDC. Se você instalou pacotes
@tanstack/*no dia 11 de maio, sua máquina ou CI pode estar comprometida. Veja abaixo como auditar, remediar e configurar seu ambiente para que isso não aconteça de novo.
Em maio de 2026, a comunidade JavaScript recebeu um alerta crítico: pacotes @tanstack/* foram comprometidos e versões maliciosas chegaram ao npm.
Este incidente não é apenas sobre uma biblioteca específica; é um estudo de caso sobre a fragilidade do modelo de confiança moderno. O postmortem oficial foi exemplar, mas o recado para nós, desenvolvedores, é maior: seu código é tão seguro quanto a parte mais fraca da sua cadeia de suprimentos.
O que realmente aconteceu (O Anatomia do Ataque)
Não foi uma senha vazada. Foi uma combinação cirúrgica de três falhas no pipeline:
- Exploração de Permissões: Um workflow com
pull_request_targetexecutou código vindo de um fork malicioso. - Poisoning de Cache: O atacante "envenenou" o cache do GitHub Actions, fazendo com que builds legítimos restaurassem conteúdo malicioso.
- Extração de Identidade: O payload extraiu tokens OIDC da memória do runner para publicar no npm como se fosse o mantenedor oficial.
O payload buscava silenciosamente por segredos: GitHub, npm, AWS, GCP, Kubernetes, Vault e chaves SSH. Se rodou no seu CI ou na sua máquina local, o atacante pode ter suas chaves agora.
Por que isso importa (Mesmo se você não usa TanStack)
O risco é sistêmico. Quando bibliotecas com bilhões de downloads como TanStack Query ou Axios (comprometido em março de 2026) são atingidas, o impacto é global.
Relatórios da ReversingLabs apontam um aumento de 73% em pacotes maliciosos em 2025. O alvo não é mais o servidor de produção; é a máquina do desenvolvedor e o runner de CI.
Guia de Sobrevivência: Se você instalou algo no dia 11
Se houve atividade no dia 11 de maio de 2026, trate o ambiente como comprometido. Não basta atualizar o pacote.
1. Detecte o Invasor
Procure por indicadores de comprometimento (IoCs) imediatamente:
# Busca pelo payload principal
find node_modules/@tanstack -name "router_init.js"
# Busca por hashes maliciosos conhecidos
grep -r "voicproducoes\|79ac49eedf" node_modules/@tanstack/*/package.json2. Contenção e Limpeza
Se encontrar algo, a ordem dos fatores altera o resultado:
- Isolamento: Desconecte a máquina ou o runner da rede.
- Persistência: Remova serviços suspeitos como o
gh-token-monitor. - Revogação: A partir de uma máquina limpa, invalide TODOS os tokens (AWS, npm, GitHub, SSH).
Fortalecendo seu .npmrc (A Primeira Linha de Defesa)
Você pode comprar tempo e segurança com configurações simples no npm v11+. Use este baseline para reduzir drasticamente sua superfície de ataque:
# Bloqueia execução automática de scripts maliciosos na instalação
ignore-scripts= true
# Regra de Quarentena: só instala pacotes com mais de 7 dias de vida
min-release-age= 7
# Segurança de Versão: evita surpresas com updates automáticos (^ ou ~)
save-exact= true
# Bloqueia dependências vindo direto do Git
allow-git= noneNo CI, use sempre: npm ci --ignore-scripts.
Lições para o seu Pipeline
- Menor Privilégio: Dê
id-token: writeapenas para jobs que realmente publicam. - SHA-Fixing: Fixe GitHub Actions pelo SHA completo, nunca pela tag (ex:
@v3). - Cache Segregado: Trate o cache como uma fronteira de confiança. Limpe-o após qualquer suspeita.
- Egress Block: Bloqueie conexões de saída desnecessárias nos runners.
Conclusão: Higiene é a Nova Defesa
O caso TanStack mostra que até os melhores podem ser alvos. Para nós, a defesa começa com hábitos de engenharia:
- Instale menos dependências no impulso.
- Trate sua máquina de dev como parte da infraestrutura de produção.
- Atrase a adoção de versões "sangue novo" (recém-publicadas).
E você? Já auditou seus segredos de CI esta semana? Compartilhe este guia com seu time e vamos elevar a barra da nossa segurança coletiva.