Ataque ao TanStack: como 84 versões maliciosas vazaram credenciais

Se você instalou algum pacote @tanstack/* no dia 11 de maio de 2026 entre 19:20 e 19:26 UTC, seu ambiente pode estar comprometido. Um ataque coordenado combinou três vulnerabilidades para publicar 84 versões maliciosas em 42 pacotes. O pior: o payload não só roubava credenciais, mas também se auto-propaga para outros pacotes mantidos pela vítima.

O fato

Um atacante aproveitou o padrão 'Pwn Request' do GitHub Actions (usando pull_request_target), envenenou o cache do Actions e extraiu tokens OIDC da memória do runner. Com isso, publicou versões maliciosas de pacotes como @tanstack/react-router, @tanstack/react-query (e outros). Nenhum token npm foi roubado, mas o estrago foi feito: quem instalou as versões afetadas executou um script que coletava credenciais de AWS, GCP, Kubernetes, Vault, npm, GitHub e chaves SSH, exfiltrando tudo via rede Session/Oxen.

Como funciona (visão de operador)

A cadeia de ataque usa três etapas, cada uma necessária, nenhuma suficiente sozinha. Primeiro: um workflow 'bundle-size.yml' rodava em pull_request_target e checkout do merge do fork. O autor tentou separar trust (comentários versus benchmarks), mas esqueceu que actions/cache@v5 não respeita permissions: o salvamento pós-job usa um token interno, não o GITHUB_TOKEN. Então um fork malicioso podia envenenar o cache.

Segundo: o cache envenenado continha um script de build alterado. Quando o workflow rodava para PRs legítimos, o cache restaurado executava código arbitrário. Terceiro: dentro do runner, o ataque extraía o token OIDC via /proc/self/environ e usava para autenticar como o repositório base, publicando versões npm.

O payload (~2.3 MB, ofuscado como router_init.js) era baixado via optionalDependencies e executado no lifecycle prepare. Ele varria o sistema em busca de credenciais, exfiltrava via Session (criptografia fim-a-fim, sem C2 controlado pelo atacante) e, por fim, enumerava outros pacotes do mantenedor e republicava com o mesmo código malicioso.

O que isso muda na prática

Se você usa TanStack, a primeira ação é verificar se instalou alguma versão entre 19:20 e 19:26 UTC do dia 11/05/2026. A lista completa de pacotes e versões está no tracking issue (GHSA-g7cv-rxg3-hmpx). Se tiver instalado, considere o host comprometido. Rode uma auditoria de credenciais: AWS IMDS, GCP metadata, tokens Kubernetes, Vault, ~/.npmrc, tokens GitHub, chaves SSH. Rotacione tudo que estiver acessível.

Quem ganha? Atacantes de supply chain, que agora têm um blueprint funcional. Quem perde? Qualquer equipe que dependa de pull_request_target sem cache isolation. E qualquer mantenedor que não tenha feito a lição de casa de restringir cache writes em workflows com split de trust.

Tensão / Reflexão

Isso escala? Sim. O ataque é replicável para repositórios que usam o mesmo padrão. O custo para o atacante é baixo: um fork, um PR, e um cache envenenado. O custo para o mantenedor é altíssimo: reputação, auditoria, rotação de credenciais. O problema não é apenas técnico: é de design do GitHub Actions, que ainda não fornece uma maneira nativa de isolar caches entre forks e base. A solução manual (separar workflows, usar API de cache com scoped keys) é frágil e fácil de errar.

A reflexão prática: você confia no seu pipeline de CI? Quantos workflows usam pull_request_target sem revisão de segurança? O ataque ao TanStack mostra que mesmo projetos bem mantidos podem cair. A pergunta que fica: quantos outros repositórios estão vulneráveis agora?

Conclusão

Um ataque de supply chain bem executado, combinando falhas de design e configuração. A defesa exige reavaliar todo pipeline de CI que lida com forks, especialmente o uso de cache. A pergunta que deixo: seu pipeline está preparado para o próximo 'Pwn Request'?