A cadeia de comprometimento de TanStack, Nx Console e GitHub (maio de 2026): o que os desenvolvedores devem verificar

Os pacotes afetados são 42 pacotes Router/Start, 84 versões, incluindo @tanstack/react-router, @tanstack/react-start, @tanstack/router-core e @tanstack/history (lista completa no aviso do GitHub GHSA-g7cv-rxg3-hmpx). A TanStack afirma que Query, Table, Form, Virtual e seus outros pacotes não foram afetados. Verifique não apenas o conteúdo atual do seu lockfile, mas também o histórico de alterações dele em torno de 11 de maio de 2026. As versões maliciosas foram removidas do npm em poucas horas, então uma instalação feita nessa janela pode não aparecer no lockfile atual. No CI, procure jobs que executaram uma instalação após 19:20 UTC de 11 de maio.

O pós-mortem do Nx mostra como verificar a versão instalada com code --list-extensions --show-versions (o ID da extensão contém angular-console). Apenas a v18.95.0 foi afetada, e ela esteve disponível em 18 de maio entre 12:30 e 13:09 UTC. O Nx pede que quem tinha o Nx Console com atualização automática habilitada durante essa janela trate a máquina como comprometida, independentemente de qual número de instalações se confirme como correto. O pós-mortem também lista arquivos e processos a procurar (indicadores de comprometimento); se você foi afetado, percorra essa lista.

A TanStack e o Nx listam os mesmos alvos: tokens do GitHub, tokens do npm, chaves SSH, credenciais de nuvem (AWS, GCP, Azure), Kubernetes, tokens do Vault e o conteúdo de qualquer arquivo .env. O Nx acrescenta as credenciais que ferramentas da máquina poderiam ter gerado durante a janela (credenciais temporárias de nuvem, tokens da GitHub CLI e assim por diante) e recomenda considerar uma reconstrução completa da máquina após a rotação. Para a ordem de revogação e como lidar com malware residente, veja a seção "se você suspeita de infecção" de Defendendo-se contra worms de supply chain no npm.

Segundo a TanStack, o código procurava outros pacotes que a vítima mantém e tentava republicá-los com a mesma injeção. Se você publica no npm, verifique o histórico de versões dos seus pacotes em busca de versões que você não publicou desde 11 de maio.

Segundo o Nx, a credencial roubada era um token da GitHub CLI. Nesse ambiente, ele estava armazenado em um arquivo no disco e legível por qualquer processo executado como o usuário, e foi usado contra a API do GitHub em até 74 segundos. Execute gh auth status para ver onde o seu está armazenado; se ele estiver em um arquivo de texto simples, considere movê-lo para o chaveiro do sistema operacional ou para uma integração com gerenciador de senhas que injete a credencial somente em tempo de execução. Após o incidente, a política do Nx passou a proibir o uso direto da GitHub CLI em máquinas de desenvolvedores. Para reduzir a duração e o escopo dos tokens, veja Defendendo-se contra worms de supply chain no npm.

Segundo o Nx, o projeto do contribuidor comprometido tinha minimum-release-age=10080 (7 dias) no seu .npmrc, mas o projeto fixava o pnpm 10.14, que não suporta essa configuração e a ignorou silenciosamente. O suporte começa com o pnpm 10.16. A versão maliciosa tinha apenas 77 minutos no momento da instalação, então uma configuração funcional a teria bloqueado. Verifique a versão fixada no campo packageManager do package.json e faça o CI verificar se ela é suficientemente recente. A configuração equivalente para o npm está em Defendendo-se contra worms de supply chain no npm.

Em 26 de maio, o GitHub anunciou que está rotacionando chaves, incluindo a chave que assina os pacotes de atualização do GitHub Enterprise Server. Os administradores devem rotacionar as chaves públicas GPG em sua instância; caso contrário, as atualizações futuras falharão com um erro informando que o arquivo não é um pacote GHES válido. As instruções e o digest SHA256 do script auxiliar estão na publicação do GitHub. O GitHub também pede que os clientes baixem as atualizações do GHES apenas da fonte oficial e se preparem para receber atualizações de segurança com mais frequência nos próximos meses. Clientes do GitHub Enterprise Cloud não precisam tomar nenhuma providência.

Segundo a TanStack, um workflow de tamanho de bundle era executado em pull_request_target e, dentro dele, fazia checkout e compilava código de um pull request de fork. O pull_request_target roda com os privilégios do repositório base, e a TanStack observa que a barreira de aprovação para contribuidores de primeira viagem não se aplica a esse gatilho. Mantenha-o apenas para tarefas que nunca executam código externo, como aplicar rótulos e comentar. Após o incidente, a TanStack removeu todo uso de pull_request_target do seu CI.

Segundo a TanStack, o cache do GitHub Actions é compartilhado por repositório: execuções de pull_request_target e envios para a main usam o mesmo escopo. Além disso, o salvamento de cache também não é bloqueado ao definir permissions: do workflow como somente leitura. Como resultado, o workflow de release restaurou um cache gravado por um job que havia executado código externo. Após o incidente, a TanStack desativou o cache de pacotes em seu pipeline de release e limpou todos os caches. Não restaurar caches em workflows que publicam é a linha mais simples de traçar.

O workflow de release da TanStack tinha id-token: write para o trusted publishing do npm (OIDC). Segundo o pós-mortem, a publicação maliciosa não partiu da etapa de publicação definida no workflow; código executado em outra etapa da mesma execução extraiu um token e publicou diretamente. A lição da própria TanStack é que um vínculo de publicador confiável não tem revisão por publicação. Separe a publicação em um job próprio, apartado da compilação e dos testes, dê essa permissão somente a esse job e coloque-o atrás de um ambiente do GitHub com revisores obrigatórios. Após o incidente, o Nx tornou obrigatória, para a publicação, a aprovação de alguém diferente da pessoa que disparou a execução.

Após o incidente, tanto a TanStack quanto o Nx fixaram cada referência de ação em um SHA de commit, em vez de uma tag ou branch. A TanStack descreve as referências móveis como "risco permanente à cadeia de suprimentos, independente deste incidente".

O Nx detectou a versão adulterada graças ao e-mail de notificação de rotina que o marketplace de extensões envia a cada upload. Um mantenedor que não esperava uma versão a reconheceu como anômala e a removeu em cerca de 11 minutos. O segundo canal de distribuição não tinha essa notificação, e a remoção ali levou cerca de 36 minutos. Enquanto isso, atividades realizadas com o token roubado, como a exclusão de execuções de workflow, ficaram no log de auditoria por uma semana sem serem percebidas. Verifique se as notificações de publicação chegam a alguém da equipe e se alguém acompanha o log de auditoria em busca de execuções de workflow excluídas.