Mini Shai-Hulud: TanStack, OpenAI e a Supply Chain do npm

A mais recente campanha de ataque à cadeia de abastecimento não se limitou a comprometer registos de código aberto. Ela comprometeu o processo de lançamento de software numa das organizações mais preocupadas com a segurança do mundo, e o ponto de entrada foi uma instalação de rotina de uma dependência do npm.

Em 11 de maio de 2026, o grupo de ameaças TeamPCP lançou a quarta vaga da sua campanha do worm Shai-Hulud, agora conhecida como Mini Shai-Hulud. O ataque comprometeu 84 versões de pacotes maliciosos em 42 pacotes TanStack no registo npm num intervalo de seis minutos, acabando por se expandir para mais de 170 pacotes nos registos de código-fonte npm e PyPI (Python Package Index), incluindo namespaces pertencentes à Mistral AI, UiPath e OpenSearch. Pelo menos um pacote afetado, @tanstack/react-router, recebe aproximadamente 12 milhões de downloads semanais.

Esta é a quarta vaga de uma campanha cada vez mais intensa. As vagas anteriores incluem o ataque inicial ao npm (Shai-Hulud 1.0) e a vaga 2.0, que teve como alvo as credenciais do GitHub.

A OpenAI revelou esta semana que dois dispositivos de funcionários foram comprometidos. Não foram afetados dados de utilizadores, sistemas de produção nem propriedade intelectual, mas as medidas de contenção exigiram o isolamento de sistemas, a renovação de credenciais, o recurso a peritos forenses externos e uma renovação total dos certificados de assinatura de código no macOS, Windows, iOS e Android, desencadeada pela instalação de uma única dependência.

• Data do ataque: 11 de maio de 2026

• Pacotes comprometidos: 84 versões maliciosas em 42 pacotes @tanstack/*; mais de 170 no total nos registos npm e PyPI

• CVE: CVE-2026-45321, pontuação CVSS 9,6 (Crítica)

• Atribuição: TeamPCP (também conhecido como PCPcat, UNC6780)

• Mecanismo: Três vulnerabilidades encadeadas no GitHub Actions — Pwn Request, envenenamento de cache e extração de tokens OIDC (OpenID Connect) da memória do processo do executor

• Vítima de destaque: OpenAI — dois dispositivos de funcionários foram comprometidos; foram exfiltrados segredos, incluindo certificados de assinatura de código para macOS, iOS, Windows e Android, a partir de repositórios internos de código-fonte

• Versões anteriores: Shai-Hulud 1.0 (setembro de 2025), 2.0 (novembro de 2025) e 3.0 (dezembro de 2025)

• Impacto: Ambientes de desenvolvimento e CI/CD comprometidos , contas de mantenedores e pacotes invadidos, e a proveniência SLSA e as compilações assinadas deixaram de ser «seguras por predefinição»

• Principais riscos: Pacotes maliciosos que passam na certificação de proveniência de nível três da SLSA (Níveis da Cadeia de Abastecimento para Software )

A Mini Shai-Hulud Wave Four é a versão tecnicamente mais sofisticada desta campanha até à data. Enquanto as fases anteriores dependiam de contas de administradores comprometidas para publicar diretamente pacotes maliciosos, a Wave Four combinou três vulnerabilidades do GitHub Actions para se apropriar do próprio pipeline de lançamento legítimo.

A sequência do ataque:

1. Fork e disfarce: O atacante fez um fork do repositório TanStack/router, renomeando-o para zblgg/configuration, para que não aparecesse como um fork óbvio nas visualizações da lista de forks do GitHub.
2. Acionar o fluxo de trabalho: foi aberto um pedido de integração que acionou o fluxo de trabalho «pull_request_target» — o padrão «Pwn Request», que concede acesso ao fluxo de trabalho ao código bifurcado
3. Contaminar a cache: o código da ramificação do atacante inseriu uma entrada contaminada de 1,1 GB do pnpm-store na cache do GitHub Actions, indexada de forma a que o fluxo de trabalho de lançamento a restaurasse posteriormente
4. Apagar os vestígios: O pedido de pull malicioso foi então submetido à força para um estado inativo e encerrado, a fim de ocultar as provas da violação
5. Aguarde o gatilho: quando os mantenedores legítimos do TanStack fundiram pedidos de pull não relacionados no ramo principal, o fluxo de trabalho de lançamento foi acionado e restaurou o cache corrompido
6. Steal the token: Attacker-controlled binaries read /proc/<pid>/mem of the Runner.Worker process to extract the OIDC token minted for npm trusted publishing
7. Publicação através do pipeline: Esses tokens foram utilizados para publicar 84 versões maliciosas de pacotes no registo do npm através do próprio pipeline de lançamento legítimo da TanStack.
8. O resultado: pacotes com atestados de proveniência válidos de nível de compilação 3 do SLSA, atestados válidos do Sigstore e assinaturas legítimas do GitHub Actions, produzidos pelo pipeline de lançamento legítimo, mas contendo malware destinado a roubar credenciais. Tal como a TanStack confirmou na sua análise pós-incidente, do ponto de vista do programador, os pacotes pareciam criptograficamente autênticos, sem qualquer indício visível de comprometimento.

Segredos foram expostos: a carga útil do malware extraiu segredos expostos — credenciais e tokens que estavam ativamente acessíveis nos sistemas comprometidos — através de três canais redundantes: um domínio de typosquatting (git-tanstack[.]com), a rede descentralizada de mensagens Session e pontos API do GitHub utilizando tokens roubados. As credenciais visadas incluíram tokens do GitHub, segredos na nuvem da AWS, GCP e Azure, material de autenticação de CI/CD, credenciais do Kubernetes, Vault HashiCorp Vault e chaves SSH.

Nos computadores dos programadores, o malware instalava um daemon persistente chamado gh-token-monitor (através do LaunchAgent do macOS ou do systemd do Linux) que consultava o GitHub a cada 60 segundos. Ao receber um erro 40X devido à revogação do token, o daemon tentava executar o comando rm -rf ~/, apagando o diretório pessoal do utilizador. O daemon encerrava automaticamente após 24 horas.

A divulgação da OpenAI é precisa quanto ao que foi extraído: material de credenciais limitado proveniente de um subconjunto de repositórios de código-fonte internos acessíveis aos dois funcionários afetados, incluindo certificados de assinatura de código para produtos macOS, iOS, Windows e Android. A OpenAI confirmou que não há provas de que esses certificados tenham sido utilizados para assinar software malicioso, mas está a substituí-los todos por precaução e a exigir que os utilizadores do macOS atualizem as suas aplicações antes de 12 de junho de 2026, data após a qual as aplicações assinadas com os certificados antigos poderão deixar de funcionar.

Há um segundo pormenor na divulgação da OpenAI que merece atenção. Os dois dispositivos comprometidos ainda não tinham recebido as configurações atualizadas de gestão de pacotes, incluindo controlos como verificações da idade mínima das versões e validação da proveniência dos pacotes, que estavam a ser implementadas em todo o ambiente da organização. O ataque ocorreu durante esse período de implementação.

Isto descreve uma lacuna real e comum. Os controlos de segurança são implementados de forma gradual. Durante qualquer implementação faseada, um subconjunto de sistemas fica mais exposto. A campanha da TeamPCP decorreu de forma contínua ao longo de várias semanas, publicando pacotes maliciosos nos registos e aguardando que fossem instalados. O momento escolhido não foi por acaso.

Para qualquer organização que possa ter instalado pacotes afetados durante o período do Mini Shai-Hulud:

1. Verifique se o daemon gh-token-monitor está em execução antes de revogar os tokens: isole e faça uma imagem dos sistemas afetados primeiro; uma revogação prematura aciona a carga de limpeza.
2. Alterne as credenciais expostas: PATs do GitHub, tokens do npm, chaves SSH e credenciais de nuvem para qualquer programador ou pipeline que tenha instalado pacotes durante o período afetado; ative a autenticação de dois fatores (MFA).
3. Remova os pacotes comprometidos: limpe a cache do npm e a pasta node_modules; fixe as versões dos pacotes publicadas após 12 de maio de 2026.
4. Audite as ações do GitHub e os fluxos de trabalho de CI/CD: procure eventos de publicação inesperados, novos fluxos de trabalho ou ligações de saída para pontos finais desconhecidos.
5. Fortaleça os pipelines: restrinja os scripts de ciclo de vida, limite o acesso à rede externa e minimize o escopo dos tokens.
6. Combine as verificações de proveniência com a inspeção de conteúdo: uma proveniência válida indica a origem do fluxo de trabalho, não a sua integridade; utilize a análise de malware em conjunto com a verificação de atestados.