Ataque supply chain npm: 3 lições do caso TanStack

Em 10 de maio de 2026, um pull request malicioso deu início a um ataque supply chain npm contra bibliotecas do TanStack, como Router e Query. O código roubava segredos de CI/CD e se espalhava pelas dependências. No dia 11, o problema já estava resolvido — mas o estrago potencial era enorme.

O que foi o ataque supply chain npm contra o TanStack?

O ataque supply chain npm contra o TanStack começou em 10 de maio de 2026, quando uma conta suspeita abriu um pull request malicioso no repositório do TanStack Router. O código infectou pacotes oficiais publicados no npm e roubou segredos de projetos que instalaram as versões comprometidas. Segundo o relato do video de Felipe Rocha, do canal Full Stack Club, bibliotecas como TanStack Router, TanStack Query e TanStack Start foram afetadas.

O caso assustou porque atinge ferramentas presentes no dia a dia de quem trabalha com React, Next.js e Node.js. O autor do vídeo mesmo reforça que não é especialista em segurança e recomenda ler o material oficial para os detalhes técnicos. Ainda assim, a sequência de eventos que ele descreve serve de aula prática sobre como um ataque de cadeia de suprimentos funciona.

A lição central é desconfortável: você não precisa ter código ruim para ser vítima. Basta que uma das suas dependências, ou a pipeline que publica uma dependência, seja comprometida em algum ponto da cadeia.

Como o pull request envenenou o cache do GitHub Actions?

O vetor do ataque foi a combinação entre um pull request e o cache de builds das GitHub Actions. Quando um pull request é aberto, é comum a pipeline rodar testes, build e type check automaticamente. Para acelerar esse processo, o cache de dependências é reutilizado entre execuções diferentes.

O fluxo descrito no vídeo funcionou assim:

1. A conta atacante criou um fork do TanStack Router e abriu um pull request com um script prepare malicioso, que apontava para um arquivo chamado tstackrunner.js.
2. Ao abrir o PR, a pipeline executou um install de dependências, e o script prepare rodou junto.
3. Esse script injetou código malicioso no cache do GitHub Actions.
4. O cache é compartilhado entre runs, então execuções seguintes — inclusive o build oficial que gera a publicação no npm — consumiram o conteúdo contaminado.
5. O pacote publicado no npm saiu com o malware embutido.

O detalhe perverso é que o pull request nem foi mesclado. Ele serviu apenas de cavalo de Troia para chegar ao cache. Como pipelines mais rápidas custam menos, o cache é uma prática recomendada — e foi exatamente essa otimização que virou porta de entrada.

Por que o script prepare é um vetor de ataque?

O script prepare faz parte do ciclo de vida de pacotes documentado pelo npm: ele roda automaticamente durante a instalação de dependências, inclusive com pnpm install e equivalentes. Isso significa que baixar um pacote já executa código no seu computador, antes de você usar qualquer função dele.

No caso do TanStack, o prepare malicioso rodou dentro da pipeline, não na máquina do desenvolvedor — pelo menos no primeiro estágio. Mas, depois que o pacote comprometido foi publicado, quem instalou as versões afetadas executou o malware localmente em um simples npm install.

Esse é o motivo pelo qual auditorias de dependências olham para scripts de ciclo de vida. Um código que roda na instalação tem acesso ao ambiente inteiro: variáveis de ambiente, arquivos de configuração e credenciais salvas no projeto.

O que o malware fazia depois de instalado?

De acordo com o relato do vídeo e o postmortem publicado pelo time do TanStack, o malware tinha dois comportamentos principais: roubar segredos e se espalhar.

• Roubo de credenciais: o código capturava secrets do projeto, como senhas de banco de dados e tokens de CI/CD. Por isso, a orientação imediata foi regenerar todas as variáveis sensíveis de quem instalou as versões afetadas.
• Propagação em cadeia: depois de comprometer um pacote, o malware tentava comprometer as dependências desse pacote, e as dependências das dependências. É esse efeito bola de neve que torna um ataque de supply chain tão grave para todo o ecossistema.
• Alteração de arquivos locais: o malware também modificava o arquivo settings. do Claude Code, a ferramenta de codificação da Anthropic que roda no terminal, inserindo um hook de session start com código malicioso.

Esse último ponto é inusitado e serve de alerta: ferramentas de IA no terminal leem arquivos de configuração e executam comandos, então viram alvo interessante. Quem usou Claude Code depois de instalar os pacotes comprometidos deveria revisar o settings. à procura de hooks que não criou.

Qual foi a linha do tempo do incidente?

A janela de exposição foi curta, mas suficiente para causar danos. Conforme relatado no vídeo, com base no postmortem oficial, o pull request malicioso foi aberto em 10 de maio de 2026 e a equipe do TanStack resolveu o problema já no dia 11 de maio de 2026.

Em cerca de 24 horas, o ataque conseguiu alcançar os pacotes publicados. Quem instalou as dependências afetadas entre 10 e 11 de maio de 2026 está na zona de risco e precisa agir. A resposta rápida da equipe limitou o estrago, mas o episódio mostra como uma janela de horas basta em um ataque desse tipo.

Vale comparar com outros incidentes recentes do ecossistema JavaScript, como o episódio envolvendo o Next.js citado no vídeo. A frequência crescente desses casos indica que segurança de cadeia de suprimentos deixou de ser assunto só de times de AppSec.

O que fazer agora para proteger seus projetos?

Se você mantém projetos JavaScript em produção, o checklist abaixo resume as ações recomendadas no vídeo e nas boas práticas do próprio incidente:

1. Verifique as dependências. Confira se algum projeto seu instalou as versões comprometidas dos pacotes do TanStack, seja no package. ou no lockfile.
2. Atualize os pacotes. Se encontrou uma versão afetada, atualize para a versão corrigida imediatamente.
3. Regenere segredos. Troque senhas de banco de dados, tokens de API e credenciais de CI/CD que possam ter passado pelo ambiente comprometido. Prioridade máxima se o projeto está em produção.
4. Revise o settings. do Claude Code. Procure hooks de session start ou qualquer alteração que você não tenha feito, inclusive no macOS.
5. Alerte o time. Comunique a equipe, registre o incidente e trate a troca de credenciais como prioridade 01.
6. Revise suas pipelines. Avalie quais actions rodam em pull requests de forks e se o uso de cache compartilhado está seguro no seu contexto. A documentação das GitHub Actions traz guias de endurecimento para esses cenários.

Se você não é especialista em segurança, uma saída prática sugerida no vídeo é colar o postmortem em uma ferramenta de IA e pedir ajuda para auditar seus projetos em busca das bibliotecas afetadas.

O que é um postmortem e por que ele importa?

Postmortem é o documento que um time escreve depois de um incidente grave. Ele registra o que aconteceu, as causas, as medidas de contenção e as mudanças que evitam a repetição do problema. É um formato consolidado na indústria, especialmente após vazamentos de segurança e falhas em produção.

O time do TanStack publicou o postmortem do incidente listando os pacotes afetados, explicando o comportamento do malware e detalhando o mecanismo do cache. Ler esse tipo de documento é uma das formas mais eficientes de entender ataques reais, porque descreve o cenário exato: qual trigger rodou, qual script executou e como o código chegou ao npm.

Para o seu time, o postmortem alheio é um template gratuito de aprendizado. Pergunte sempre: a mesma falha existiria na nossa pipeline? Quem pode abrir pull requests que disparam actions com acesso a segredos?

Perguntas frequentes

• O pull request malicioso chegou a ser mesclado no branch principal? Não. Segundo o relato do incidente, o PR nunca foi mesclado. O dano ocorreu porque a abertura do pull request disparou uma pipeline que executou o script prepare e contaminou o cache reutilizado por builds seguintes.

• Preciso trocar minhas senhas mesmo sem usar os pacotes afetados? Se nenhum projeto seu instalou as versões comprometidas entre 10 e 11 de maio de 2026, o risco direto é baixo. Ainda assim, vale conferir lockfiles de todos os repositórios, incluindo projetos antigos e ambientes de produção.

• Como descubro se instalei uma versão comprometida? Verifique o package. e o arquivo de lock de cada projeto, comparando com a lista de pacotes e versões do postmortem oficial do TanStack. Ferramentas de IA podem ajudar a varrer vários repositórios de uma vez.

• Como posso transformar um vídeo como esse em artigo? Se você acompanhou esse incidente por vídeo e quer registrar o aprendizado em texto, o Skala Blog converte a transcrição de um YouTube em artigo estruturado: você cola o link, o vídeo é transcrito e o artigo é gerado para você revisar.

Do vídeo ao artigo: registre o que você aprendeu

Incidentes como esse passam rápido: em 24 horas o assunto saturou as redes e sumiu dos feeds. Transformar a explicação em texto é uma forma de o conhecimento ficar pesquisável e útil por muito mais tempo.

Se você produz conteúdo em vídeo sobre programação, segurança ou qualquer outro tema técnico, o fluxo é simples: você cola a URL de um vídeo do YouTube no Skala Blog, o conteúdo é transcrito e um artigo estruturado é gerado para sua revisão. O que você explicou falando vira material escrito, pronto para ser encontrado por quem precisar dele depois.

Source video