TeamPCP publica código‑fonte do worm Shai‑Hulud e expõe novo risco para a cadeia de suprimentos de software

A divulgação pública do código‑fonte completo do worm Shai‑Hulud no GitHub pelo grupo TeamPCP, sob a permissiva licença MIT, transformou um ataque recente à cadeia de suprimentos de software em algo ainda mais preocupante: um modelo de ataque reutilizável que qualquer pessoa pode estudar, modificar ou replicar.

O código apareceu em dois repositórios e foi rapidamente replicado por outros usuários — acumulando dezenas de forks em poucas horas, um sinal de como ferramentas ofensivas podem se espalhar rapidamente quando são publicadas abertamente.

Essa divulgação ocorreu logo após um ataque coordenado em 11 de maio de 2026 que comprometeu mais de 170 pacotes nos registries npm e PyPI, dois dos maiores repositórios de dependências usados por desenvolvedores em todo o mundo. Entre os ecossistemas afetados estavam projetos ligados a TanStack, Mistral AI, UiPath, OpenSearch e Guardrails AI.

Para equipes de segurança, o acesso ao código real oferece uma oportunidade rara de analisar o funcionamento de um worm moderno de supply chain. Ao mesmo tempo, ele reduz drasticamente o esforço necessário para que outros atacantes adaptem ou reutilizem a técnica.

Do ataque à ferramenta pública

A campanha Shai‑Hulud chamou atenção pela velocidade e escala. Em 11 de maio de 2026, invasores associados ao TeamPCP publicaram versões maliciosas de pacotes populares em npm e PyPI, distribuindo centenas de releases comprometidos em poucas horas.

O diferencial foi o comportamento autopropagante do malware. Em vez de comprometer apenas um pacote, o worm podia se espalhar dentro do ecossistema de desenvolvimento depois que as primeiras dependências infectadas eram instaladas.

Pouco depois, pesquisadores relataram que o grupo publicou o código completo do worm em repositórios do GitHub, permitindo reutilização e modificação irrestritas por qualquer pessoa graças à licença MIT.

Por que a licença MIT muda o cenário

Publicar malware com uma licença aberta é incomum — e tem implicações importantes.

Para defensores, o código aberto permite:

• criar regras de detecção mais precisas (YARA, Sigma, EDR);
• reproduzir o comportamento do worm em ambientes controlados;
• validar se ferramentas de segurança e pipelines CI/CD detectam o ataque.

Para atacantes, a mesma transparência reduz barreiras técnicas. A licença MIT permite copiar, modificar e redistribuir o código praticamente sem restrições, o que facilita adaptar o worm para novos ecossistemas de pacotes ou técnicas de evasão.

Em outras palavras, o Shai‑Hulud deixa de ser apenas um incidente específico e passa a funcionar como um “manual” de exploração da cadeia de suprimentos de software.

Principais capacidades do worm Shai‑Hulud

Relatórios de segurança mostram que o malware combina várias técnicas avançadas usadas em ataques modernos à cadeia de desenvolvimento.

Roubo de tokens OIDC em pipelines CI/CD

Uma das funcionalidades mais críticas do worm é a capacidade de extrair tokens OpenID Connect (OIDC) de pipelines CI/CD, especialmente de workflows do GitHub Actions usados para publicar pacotes.

Em vez de depender apenas de credenciais estáticas roubadas, os invasores capturam tokens temporários diretamente durante a execução do pipeline, permitindo publicar novas versões maliciosas através da própria automação confiável do projeto.

Publicação de pacotes com procedência aparentemente válida

Outro aspecto preocupante é que os pacotes maliciosos foram publicados com atestados de procedência SLSA Build Level 3 válidos, um mecanismo criado justamente para garantir integridade na cadeia de build.

Na prática, os artefatos pareciam legítimos porque vinham de pipelines confiáveis — mesmo contendo código malicioso.

Roubo de credenciais em ambientes de desenvolvimento

Depois de instalado, o worm ativa um stealer capaz de coletar dados sensíveis em máquinas de desenvolvedores e ambientes de CI.

Entre os alvos relatados estão:

• credenciais de nuvem (como AWS);
• chaves privadas SSH;
• tokens de publicação npm e PyPI;
• tokens pessoais do GitHub (PAT);
• segredos de Kubernetes e HashiCorp Vault.

Alguns relatórios indicam que o malware verifica mais de 100 caminhos comuns de armazenamento de credenciais nos sistemas comprometidos.

Propagação automática pelo ecossistema de pacotes

Com credenciais roubadas e pipelines comprometidos, o worm consegue infectar automaticamente novos pacotes, ampliando o alcance do ataque em cascata dentro dos registries de software.

Componente destrutivo (“dead‑man’s switch”)

Análises também apontam para um possível mecanismo destrutivo semelhante a um wiper, que pode apagar dados caso determinadas condições sejam ativadas.

Por isso, especialistas recomendam tratar ambientes afetados como totalmente comprometidos, e não apenas limpar dependências maliciosas.

Relação com ataques anteriores do TeamPCP

A campanha de maio não foi o primeiro incidente ligado ao grupo.

Pesquisas da Cloud Security Alliance descrevem um ataque anterior entre 29 e 30 de abril de 2026, quando pacotes em npm, PyPI e Packagist foram comprometidos em cerca de 1.800 repositórios usando credenciais expostas e falhas de configuração em pipelines CI/CD.

A campanha Shai‑Hulud representa uma evolução clara:

• ataques anteriores dependiam principalmente de tokens roubados;
• o ataque de maio explorou pipelines de publicação confiáveis;
• o malware ganhou capacidade de autopropagação entre ecossistemas.

Isso mostra como grupos atacantes estão adaptando rapidamente suas técnicas para contornar novas defesas da cadeia de software.

Riscos imediatos para desenvolvedores e empresas

Organizações que instalaram pacotes comprometidos durante a janela do ataque enfrentam riscos significativos.

Especialistas recomendam que qualquer ambiente que tenha instalado uma dessas dependências seja considerado potencialmente comprometido, devido à coleta de credenciais e possível persistência do malware.

Outro aprendizado importante: assinaturas e atestados de procedência não garantem segurança absoluta se o próprio pipeline de build for comprometido.

Ações recomendadas para equipes de segurança

Para investigar possíveis impactos, especialistas sugerem:

• identificar dependências npm e PyPI instaladas ou compiladas desde 11 de maio de 2026;
• reconstruir projetos em ambientes limpos usando lockfiles confiáveis;
• rotacionar todas as credenciais de desenvolvedores, nuvem, registries e CI/CD;
• auditar workflows do GitHub Actions e pipelines de build em busca de alterações suspeitas;
• limitar publicação de pacotes a runners endurecidos e com permissões OIDC mínimas.

Também é importante monitorar novas variantes. Como o código do worm agora é público, cresce a probabilidade de versões modificadas ou ataques imitadores surgirem rapidamente no ecossistema open source.

Um alerta para a segurança da cadeia de software

O incidente Shai‑Hulud evidencia uma mudança importante: os atacantes estão mirando os próprios fluxos de trabalho dos desenvolvedores, não apenas vulnerabilidades em dependências.

Ao publicar o código do worm usado em um ataque real, o TeamPCP transformou um incidente de segurança em um modelo aberto de exploração da cadeia de software — algo que tanto defensores quanto adversários agora podem estudar em detalhes. A corrida para entender e mitigar esse modelo já começou.