O que aconteceu
Em 11 de maio de 2026, um grupo de atacantes identificado como “TeamPCP” publicou 84 versoes maliciosas de 42 pacotes do ecossistema TanStack no npm. O TanStack e uma das familias de bibliotecas JavaScript mais populares do mundo, incluindo pacotes como TanStack Query (antigo React Query), TanStack Router e TanStack Table, usados por milhoes de projetos corporativos e open source.
O ataque explorou uma cadeia de tres vulnerabilidades no GitHub Actions: o padrao “Pwn Request” (via pull_request_target), envenenamento de cache entre forks e extracao de tokens OIDC da memoria do runner. O resultado foi acesso direto ao pipeline de publicacao no npm, permitindo que o atacante distribuisse pacotes trojanizados sem alterar o repositorio principal do projeto.
Como a OpenAI foi atingida
A OpenAI confirmou que dois dispositivos corporativos foram comprometidos em consequencia do incidente. Segundo comunicado oficial da empresa a Reuters, material limitado de credenciais foi exfiltrado de repositorios de codigo. Porem, nenhum dado de usuario, propriedade intelectual ou sistema de producao foi afetado.
A causa raiz especifica na cadeia da OpenAI foi uma misconfiguracao no workflow de GitHub Actions usado para assinar o aplicativo macOS do ChatGPT. A configuracao usava uma tag flutuante (@v3) em vez de um hash de commit especifico. Quando a tag foi comprometida, o pipeline da OpenAI puxou automaticamente o codigo malicioso durante o processo de build.
A resposta incluiu isolamento imediato dos sistemas afetados, restricao temporaria de workflows de deploy e revogacao de certificados de assinatura de codigo. Usuarios do ChatGPT Desktop, Codex e Atlas no macOS foram orientados a atualizar seus aplicativos.
Um padrao que se repete
O grupo TeamPCP, que assina seus ataques como “Mini Shai-Hulud”, e o mesmo responsavel pelo comprometimento da ferramenta Trivy e de pacotes da Mistral AI em marco de 2026, usando tecnica similar. O padrao e consistente: projetos open source confiados por milhares de empresas sao comprometidos via seus pipelines de CI/CD, nao via falhas no codigo-fonte em si.
Segundo analise publicada pela Wiz, o ataque ao TanStack foi o primeiro a combinar as tres tecnicas (Pwn Request, cache poisoning e OIDC extraction) em uma unica cadeia no ecossistema npm. A sofisticacao do vetor indica que ataques de supply chain estao evoluindo rapidamente, e que a confianca implicita em dependencias populares precisa ser revisada.
O npm hospeda mais de 2 milhoes de pacotes. A maioria dos projetos corporativos depende de centenas ou milhares deles. Cada dependencia e um vetor de ataque potencial se o pipeline de publicacao do mantenedor nao tiver protecoes adequadas.
O que times de DevOps devem fazer agora
- Fixar dependencias por hash, nunca por tag. Tags e branches sao mutaveis. Um
uses: action@v3pode apontar para codigo diferente amanha. Use o SHA completo do commit:uses: action@abc123def456. - Auditar workflows que usam
pull_request_target. Esse trigger executa o workflow com permissoes do repositorio base, mesmo para PRs vindos de forks. Se combinado com checkout do codigo do PR, abre uma porta direta para injecao de codigo malicioso. - Monitorar pacotes com ferramentas de SCA. Solucoes como Snyk, Socket.dev ou Dependabot alertam quando versoes suspeitas sao publicadas. O TanStack comprometido foi detectado em menos de seis horas, mas apenas por equipes que tinham monitoramento ativo.
- Revisar permissoes de tokens OIDC. Se seus workflows emitem tokens OIDC para autenticacao com servicos cloud (AWS, Azure, GCP), valide que o escopo segue o principio de privilegio minimo.
O que observar daqui
Ataques de supply chain se tornaram o vetor preferido de grupos sofisticados porque oferecem alcance massivo com esforco concentrado. Comprometer uma dependencia popular atinge todos que a consomem, de startups a gigantes como a OpenAI.
Para empresas que operam pipelines de CI/CD em ambientes criticos, a mensagem e clara: a seguranca da cadeia de dependencias precisa ser parte do checklist basico, ao lado de testes automatizados e controle de acesso. Auditar workflows de GitHub Actions, fixar versoes por hash e monitorar pacotes com SCA nao sao praticas avancadas. Sao o minimo necessario para nao ser a proxima vitima de um incidente como este.