Mini Shai-Hulud: a campanha que expõe a fragilidade da cadeia de fornecimento de código aberto em npm, PyPI e GitHub Actions

A campanha conhecida como Mini Shai-Hulud, atribuída ao ator TeamPCP, torna claro a fragilidade da cadeia de fornecimento de código aberto: pacotes legítimos em npm e PyPI usados por projetos como TanStack, Mistral AI, OpenSearch e Guardrails AI foram alterados para incluir um carregador malicioso que não só rouba credenciais, mas também tenta persistir e propagar-se como um verdadeiro verme dentro do ecossistema de pacotes e CI/CD.

O mais preocupante deste incidente é o nível de sofisticação técnico e táctico. Os atacantes usaram um arquivo ofuscado em JavaScript ("router_init.js") para perfilar ambientes e lançar um roubador de credenciais capaz de extrair segredos de provedores cloud, carteiras de criptomoedas, ferramentas de IA, mensagens e sistemas CI como GitHub Actions. Além disso, para evitar filtros corporativos, exfiltraram dados a uma infraestrutura baseada no Session Protocol (domínio filev2.getsession[.]org) e, como plano de apoio, os subiram para repositórios GitHub usando tokens roubados sob a identidade "[email protected]".

O vetor de entrada técnico foi uma cadeia de compromissos no GitHub Actions: uso do disparador pull_ request_target, envenenamento de cache de Actions e extração em tempo de execução de tokens OIDC desde o processo do runner. Isso permitiu aos atacantes publicar pacotes maliciosos através da pipeline legítima do projeto com testes de procedência SLSA válidos, uma escalada rara e perigosa que ataca precisamente a confiança que busca garantir SLSA. Mais informações sobre como endurecer o GitHub Actions está disponível na documentação oficial: https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions, e sobre SLSA em https://slsa.dev/.

O verme também demonstrou capacidade de autorreplicação: localizava tokens de publicação npm com a bandeira bypass_2fa=true, enumerava pacotes dos mesmos mantenedores e mudava tokens OIDC por tokens por pacote para contornar a autenticação tradicional. O resultado foi a criação e propagação de versões maliciosas com SLSA Build Level 3 aparentando ser legítimas. O incidente recebeu o identificador CVE‐2026‐45321 e uma qualificação CVSS crítica de 9.6, afetando dezenas de pacotes e versões.

As amostras detectadas incluem comportamentos extremos e geofencing: análise da Microsoft sobre a amostra de Mistral descreve um download que evita ambientes de fala russa e que contém um ramo destrutivo com probabilidade de executar "rm -rf /" em certos países, enquanto o pacote comprometido guardrails-ai executava código no momento da importação que descarregava e executava um artefato remoto sem verificações de integridade. Isto ilustra não só a perda de segredos, mas o risco real de danos irreversíveis em sistemas de produção.

Para manutenção de projectos em causa ou em risco, a resposta deve ser imediata e multifacetada: revogar e rodar todos os tokens de publicação e OIDC, auditar os logs do GitHub Actions em busca de forks com payloads, commits e usos de contas suspeitas (por exemplo, "[email protected]"), revogar credenciais com bypass_2fa e desactivar ou restringir o uso de pull_request_target em fluxos de trabalho que fazem operações sensíveis. É crucial verificar os artefatos publicados e a cadeia de abastecimento: reconstruir, assinar e verificar hashes e assinaturas de pacotes antes de os aceitarem em produção.

As equipas de segurança de organizações consumidoras devem detectar e mitigar compromissos decorrentes de dependências: auditar dependências transitórias, bloquear versões comprometidas nos gestores (npm e PyPI), digitalizar ambientes de desenvolvimento e CI em busca de processos que se ligam a domínios suspeitos como filev2.getsession[.]org, api.masscan[.]cloud ou git-tanstack.com e revisar as máquinas de desenvolvedores e runners de CI por persistências em IDEs (extensões/integrações de VS Code e Claude Code) e serviços como gh-token-monitor.

Há implicações estratégicas maiores: a campanha mostra como a confiança em atestações de build pode ser manipulada se workflows legítimos e Tokens OIDC ficam expostos, pelo que as organizações devem aplicar o princípio de menor privilégio às identidades de CI, adotar caducidade curta para tokens, habilitar políticas de acesso condicional e revisar o modelo de confiança para forks externos e caches de Actions. Recomendações operacionais e de defesa podem ser consultadas no guia de endurecimento do GitHub Actions citada acima.

Do ponto de vista legal e de governança, os mantenedores devem coordenar a divulgação responsável com registros de pacotes (npm/PyPI), GitHub e, quando apropriado, autoridades regulatórias. Os consumidores devem seguir as instruções dos projetos e repositórios de segurança para atualizar ou retirar versões afetadas, e registrar evidências operacionais antes de limpar ambientes comprometidos.

Em suma, este incidente não é apenas outro pacote malicioso: é uma advertência sobre como a combinação de automação CI, tokens de alto privilégio e procedimentos de confiança podem ser explorados para introduzir malware que se propaga e persiste. A mitigação exige mudanças técnicas (rotação de credenciais, restrições a workflows, revisão de licenças), operacionais (auditorias contínuas, detecção de exfiltração) e culturais (menos confiança implícita em máquinas). Atuar rápido e coordenar com fornecedores e a comunidade é a única maneira de limitar o alcance e prevenir futuras campanhas semelhantes.