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

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.