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

> Published 2026-10-11T13:55:45.583Z on https://www.crazystack.com.br/pt/p/ataque-supply-chain-npm-3-licoes-do-caso-tanstack/
> Source video: https://www.youtube.com/watch?v=YPewAjMfdz8

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](https://tanstack.com) 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](https://docs.github.com/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](https://docs.npmjs.com/cli/v10/using-npm/scripts): 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](https://docs.anthropic.com/en/docs/claude-code/overview), 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](https://docs.github.com/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](https://skalablog.com) 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](https://skalablog.com), 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](https://www.youtube.com/watch?v=YPewAjMfdz8)