Violação da Cadeia de Suprimentos do TanStack: Quando o Software "Confiável" se Volta Contra Você

Violação da Cadeia de Suprimentos do TanStack: Quando o Software "Confiável" se Volta Contra Você

Em 11 de maio de 2026, o mundo dos desenvolvedores recebeu um alerta brutal. Entre 19:20 e 19:26 UTC, o namespace npm do TanStack — um pilar do desenvolvimento web moderno — foi sequestrado por um agente de ameaças conhecido como TeamPCP. Nesses seis minutos, eles publicaram 84 versões maliciosas em 42 pacotes diferentes @tanstack/*.

Este não foi um ataque comum de typo-squatting. Os atacantes não apenas enviaram código malicioso; eles comprometeram o próprio pipeline de build. Ao explorar vulnerabilidades no GitHub Actions, eles injetaram um worm de roubo de credenciais diretamente na cadeia de suprimentos. O detalhe mais alarmante? Cada um desses pacotes maliciosos carregava uma procedência SLSA (Supply-chain Levels for Software Artifacts) válida.

A Ilusão de Confiança

Este é um momento divisor de águas para a segurança de software. Pela primeira vez, vimos um pacote npm malicioso ser distribuído com uma procedência SLSA Build Level 3 válida. Pense nisso por um segundo. O processo de build foi tão profundamente comprometido que os atestados de segurança — as próprias ferramentas destinadas a provar que um pacote é seguro — eram tecnicamente precisos, mas fundamentalmente maliciosos.

Conforme detalhado no acompanhamento do incidente publicado pelo TanStack, o código foi projetado para ser acionado no momento em que você executasse npm install. Uma vez ativo, ele buscava tudo: chaves AWS, credenciais GCP, configurações de Kubernetes, tokens do GitHub e chaves SSH. Em seguida, ele exfiltrava silenciosamente esses dados via rede Session/Oxen. Se você estava executando esses pacotes, seus segredos estavam sendo transmitidos aos atacantes em tempo real.

A Anatomia do Ataque

O TeamPCP — que você talvez conheça por outros pseudônimos como DeadCatx3, PCPcat ou ShellForce — não parou no TanStack. Eles implantaram uma variante do worm "Mini Shai-Hulud". Em uma janela de cinco horas, a infecção se espalhou para mais de 170 pacotes no npm e no PyPI.

O post-mortem do comprometimento da cadeia de suprimentos do npm esclarece que, embora contas individuais do npm não tenham sido necessariamente hackeadas, os atacantes encontraram uma porta dos fundos através de fluxos de trabalho pull_request_target do GitHub Actions. Eles essencialmente enganaram o pipeline de CI/CD para que fizesse o trabalho pesado por eles.

Por que a Segurança Tradicional Falhou

Passamos anos dizendo aos desenvolvedores para "verificar a procedência" e "validar as assinaturas". Mas o que acontece quando o próprio ambiente de build é o mentiroso?

Como o comprometimento ocorreu na fonte, os mecanismos de confiança automatizados fizeram exatamente o que foram programados para fazer: verificaram um build "confiável" que, por acaso, continha uma carga maliciosa. Este não é apenas um problema do TanStack. Vimos padrões semelhantes em ataques recentes ao Trivy, Checkmarx KICS, LiteLLM e ao CLI do Bitwarden. Está claro que estamos diante de uma campanha coordenada de alto nível voltada diretamente para o coração da infraestrutura de CI/CD.

Se você estava usando as versões comprometidas, o aviso de segurança oficial é claro: presuma o pior. O fato de o TeamPCP estar trabalhando em conjunto com o grupo de ransomware Vect é o prego final no caixão. Eles não estão apenas roubando dados; estão coletando credenciais para facilitar ataques destrutivos em larga escala posteriormente.

A Limpeza: O Que Você Precisa Fazer Agora

Se seus pipelines de CI/CD tocaram nesses pacotes, você precisa agir como se todo o seu ambiente estivesse comprometido. Aqui está a realidade da situação:

• Destrua (ou pelo menos audite): Trate cada ambiente de CI/CD ou máquina de desenvolvimento que tocou nesses pacotes como uma cena de crime.
• Rotacione tudo: Não apenas mude suas senhas. Rotacione cada chave de API, token de nuvem e chave SSH que poderia ter sido acessada por essas máquinas. Presuma que eles já estão nas mãos dos atacantes.
• Rastreie as pistas: Verifique seus logs de CI/CD em busca de qualquer atividade de npm install ou tráfego de rede de saída estranho por volta de 11 de maio.
• Limpe suas dependências: Atualize para as versões seguras listadas no rastreamento oficial do registro de pacotes. Não presuma que seu arquivo de bloqueio (lockfile) atual é seguro.
• Fique atento ao movimento lateral: Como esses atacantes estão ligados a ransomware, fique de olho na sua rede interna. Eles estão tentando se mover do seu servidor de build para o seu ambiente de produção.

A Fragilidade da Automação

O worm "Mini Shai-Hulud" é um lembrete sombrio de que nossos pipelines de build modernos são mantidos unidos por uma frágil teia de confiança. Ao atingir o GitHub Actions, o TeamPCP contornou efetivamente as defesas de perímetro que passamos uma década construindo. Operávamos sob a suposição de que, se o ambiente de build é automatizado e "comprovado", ele deve ser seguro. Este incidente prova que essa suposição é uma falácia perigosa.

Para aqueles que desejam se aprofundar, o rastreador de problemas do repositório do TanStack router contém uma análise detalhada de como a extração do token OIDC realmente funcionou. É uma leitura sóbria sobre a facilidade com que um pipeline pode ser manipulado.

À medida que a investigação avança, a mensagem para a comunidade de desenvolvedores é simples: pare de confiar cegamente no pipeline. Chegamos a um ponto em que a integridade do ambiente de build não pode mais ser presumida — ela deve ser verificada, auditada e tratada com o mesmo ceticismo que aplicamos ao próprio código. Mantenha-se vigilante, porque os agentes de ameaças certamente não estão dormindo.