Shai-Hulud: um worm de supply chain com possível génese em AI

Em vez de escreverem cada componente de raiz, os programadores recorrem a blocos de código JavaScript — packages — partilhados por outros developers. Esta lógica de reutilização permite velocidade e inovação, mas também cria dependências invisíveis: cada aplicação moderna assenta em centenas ou milhares de packages publicados por desconhecidos, confiando que estão íntegros, que não escondem armadilhas e que não se transformam em vetores de ataque. O npm não é apenas um repositório; é a engrenagem que liga uma parte crítica do software atual.

Foi precisamente esta posição central que tornou tão grave o episódio registado em setembro de 2025, quando pelo menos 187 packages foram comprometidos por um worm auto-replicante batizado de Shai-Hulud. Ao contrário de malware tradicional que tenta ocultar-se, este código rouba tokens e outras credenciais e expõe-nas publicamente, criando de forma automática repositórios GitHub com o nome da criatura retirada de Dune. Não é apenas um ataque silencioso: é um gesto que prefere anunciar-se, exibir os despojos e deixar um rasto visível em cada movimento.

O funcionamento interno

O mecanismo do Shai-Hulud é ao mesmo tempo simples e devastador. Sempre que um package infetado é instalado, o worm procura no ambiente local tokens de autenticação npm. Se encontra um válido, modifica até vinte packages controlados por esse token, injeta neles o seu código e publica imediatamente novas versões contaminadas no repositório. Não há command and control server, não há centro a desligar: cada developer comprometido torna-se veículo da propagação. A estratégia replica a lógica biológica de um vírus, mas aplicada ao tecido da cadeia de fornecimento do software.

Para ampliar o alcance, o malware integra o TruffleHog, uma ferramenta concebida para auditorias de segurança que aqui serve para procurar API keys, chaves SSH, tokens de GitHub e credenciais de cloud AWS, Azure e Google Cloud.

Segundo a análise da Palo Alto, o worm não se limita às variáveis de ambiente: percorre ficheiros de configuração e tira partido de GitHub Actions para automatizar tanto a extração como a exposição das credenciais encontradas. O resultado é um ataque que não compromete apenas bibliotecas de código, mas também infraestruturas inteiras ligadas a pipelines de CI/CD e serviços de cloud em produção.

Sinais precursores

Este não foi o primeiro aviso. Poucas semanas antes, uma campanha de phishing dirigida a developers do npm introduzira falsos pedidos de atualização de MFA, que resultaram na publicação de malware em dezenas de packages com o objetivo de desviar pagamentos em criptomoedas. Em agosto, o nx toolkit, com milhões de downloads semanais, tinha sido adulterado para recolher credenciais e expô-las em repositórios GitHub públicos. Mas nesse caso não havia capacidade de auto-propagação. O Shai-Hulud vai mais longe: cada credencial roubada torna-se “combustível” para comprometer novos packages, desencadeando um efeito dominó que pode multiplicar-se sem controlo.

Em Dune, os vermes de areia deslocam-se debaixo da superfície até que uma vibração os chama à superfície. A metáfora não é forçada: a instalação banal de um package é a vibração que faz emergir o verme. O que parecia terreno estável revela-se um deserto instável, onde a confiança assenta em areia movediça. Cada comando de instalação pode tornar-se o passo em falso que reativa o ciclo.

Impacto imediato

Entre os afetados esteve a CrowdStrike, que viu cerca de 25 packages temporariamente comprometidos. A empresa reagiu depressa, retirando-os do repositório, rodando chaves e garantindo que os produtos principais não estavam em risco. Ainda assim, o episódio expôs fragilidades profundas. Plataformas como a StepSecurity confirmaram que o worm explorava workflows do GitHub para publicar repositórios de forma automática. O ataque mostrou que a cadeia de fornecimento não é apenas vulnerável: é por natureza fértil em pontos de entrada, porque cada token válido concede um poder quase ilimitado de publicação.

As potenciais consequências vão muito além da adulteração de bibliotecas. Credenciais expostas podem permitir acesso a buckets de cloud, instalação de ransomware, mineração de criptomoedas em larga escala ou até destruição deliberada de ambientes de produção. O Shai-Hulud não se limita a explorar o código; ameaça diretamente as infraestruturas que suportam serviços críticos.

O problema estrutural

Investigadores como Nicholas Weaver, da Universidade de Berkeley, descrevem este episódio como “um ataque à cadeia de fornecimento que executa outro ataque à cadeia de fornecimento”. O aparente paradoxo ilustra a fragilidade do modelo: um sistema que privilegia velocidade e automação sobre escrutínio humano, em que um único token pode publicar dezenas de packages sem qualquer barreira adicional. Enquanto a publicação em npm não exigir validação manual reforçada por mecanismos de autenticação antifraude, ataques deste género continuarão a repetir-se. A recomendação é clara: reduzir o alcance dos tokens, alterá-los frequentemente, aplicar MFA resistente a phishing e auditar cada dependência instalada.

Detalhes adicionais perturbadores

A Palo Alto identificou ainda um elemento curioso: com confiança moderada, considera que partes do bash script malicioso podem ter sido geradas por um modelo de linguagem (LLM), dedução baseada no estilo dos comentários e no uso insólito de emojis no código. Isto sugere que a automação não está apenas no modo como o worm se replica, mas também na forma como foi escrito, antecipando uma tendência em que atacantes recorrem a ferramentas de IA para acelerar a produção de variantes, multiplicando o número de mutações possíveis e reduzindo custos.

Além disso, o relatório da Palo Alto (Unit 42) publicou hashes de ficheiros infetados, identificadores de repositórios e indicadores de compromisso, permitindo que equipas de segurança detetem instâncias do ataque. Também forneceu orientações práticas: mudar de imediato todas as credenciais (NPM tokens, chaves SSH, GitHub PATs e API keys), auditar ficheiros, em busca de versões maliciosas, rever workflows do GitHub em busca de automatismos inesperados, e reforçar políticas de obrigatoriedade de MFA em todas as contas críticas.

Dormência não é erradicação

O endereço usado para exfiltração foi, entretanto, suspenso e o ritmo de propagação parece ter abrandado. Mas dormência não significa erradicação. O código pode permanecer latente, pronto a reiniciar o ciclo assim que um developer instale inadvertidamente um package comprometido ou reutilize um token exposto. Mais do que a astúcia de um atacante, este episódio revela a vulnerabilidade estrutural de uma infraestrutura onde confiança e automação se sobrepõem a controlo humano.

Tal como no deserto de Arrakis, nunca se sabe que vibração fará emergir novamente o verme. O que parecia firme é apenas superfície, e o Shai-Hulud recorda-nos que, na cadeia de fornecimento digital, o risco não está em incidentes pontuais, mas na própria lógica que permite multiplicá-los.