Se você trabalha com o ecossistema moderno de JavaScript/TypeScript, há uma grande chance de você usar alguma biblioteca do TanStack. Seja o onipresente TanStack Query (antigo React Query), o Table ou o novo React Router. Eles estão em quase tudo.
O ataque
E o dia 11 de maio de 2026 deu um nó no estômago de muita gente.
Para quem perdeu, o ecossistema TanStack sofreu um ataque crítico de supply chain (CVE-2026-45321). Um agente malicioso conseguiu comprometer as pipelines de CI/CD do TanStack através de um “Pwn Request” (envenenamento de cache via pull_request_target no GitHub Actions) e injetou código malicioso em 84 versões de 42 pacotes diferentes. O estrago principal foi no @tanstack/react-router, mas a stack inteira acendeu o sinal vermelho.
O pior desse tipo de ataque? O código malicioso roda imediatamente quando você ou seu servidor executa um inocente npm install.
O “Modo Crise” Ativado: O que fiz primeiro?
Quando uma CVE dessas cai no seu colo, não adianta entrar em pânico; você precisa de dados. Minha prioridade foi isolar o raio de impacto usando três passos básicos:
Cruzamento de Linha do Tempo vs. Logs de CI/CD
A primeira coisa que fiz foi abrir o post-mortem oficial do TanStack para entender a janela exata de exposição (o horário em que os pacotes maliciosos ficaram disponíveis no npm até o momento em que foram derrubados).
Com esses horários em mãos, fui direto para os logs do nosso servidor de CI/CD. Eu precisava responder a uma pergunta: “Rodamos alguma pipeline de build ou deploy automático nessa janela de tempo?”.
Felizmente, o resultado foi negativo. Nossos servidores não tocaram no npm enquanto o ataque estava ativo. Primeira barreira de segurança: OK.
Auditoria de Dependências Locais
Mesmo com o servidor seguro, o perigo mora ao lado: as máquinas dos desenvolvedores. Como usamos pacotes como @tanstack/vue-query e @tanstack/query-core, havia o risco de alguém ter rodado um npm install localmente e baixado uma versão infectada.
Alertei o time imediatamente para suspender instalações e iniciar uma varredura nas dependências para garantir que ninguém estivesse preso em uma versão buildada pelo atacante.
Deixando o rastro técnico (Governança)
Depois de mitigar o risco imediato, gastei um tempo estruturando um relatório técnico de incidente de segurança. Pode parecer burocracia, mas documentar a cronologia do evento, quais sistemas foram validados e o status final de “Não comprometido” é o que separa um time que “teve sorte” de um time que possui processos de governança de verdade.
Como garantir que seu ambiente está limpo?
Se você acha que pode ter sido exposto durante essa última semana, o caminho das pedras recomendado pelo próprio time do TanStack envolve:
- Forçar a atualização: Vá para as versões corrigidas que eles lançaram imediatamente após o incidente.
- Destruir o cache local: Não basta mudar o
package.json. Delete a pastanode_modules, delete o seupackage-lock.json(ou equivalente) e limpe o cache do seu gerenciador de pacotes (npm cache clean --force). - Inspeção do Host: O script malicioso tenta se espalhar ou coletar dados do ambiente. Vale a pena olhar a seção Detection no post-mortem deles para caçar processos ou mutações estranhas no seu diretório
.npm.
Post-mortem completo pode ser lido em: Postmortem: TanStack npm supply-chain compromise
Lições para o futuro (O olhar de Arquitetura)
Incidentes como esse nos lembram que a arquitetura do nosso software é tão forte quanto o elo mais fraco da nossa cadeia de dependências.
Monitorar CVEs manualmente não escala. Como lição de casa desse susto, o próximo passo por aqui é refinar nossas esteiras de CI/CD para incluir ferramentas de SCA (Software Composition Analysis) de forma mais agressiva, travando o build automaticamente se um package-lock tentar passar com uma dependência comprometida.
E você, como ficou sabendo desse ataque? Conseguiu rodar o diagnóstico a tempo no seu projeto?
Comments