Malware Shai Hulud v2

A segunda onda do ataque à cadeia de suprimentos Shai-Hulud atingiu o ecossistema Maven, após a violação de mais de 830 pacotes no registro npm. Pesquisadores identificaram um pacote do Maven Central, org.mvnpm:posthog-node:4.18.1, que contém os mesmos componentes maliciosos dos ataques anteriores ao npm: o carregador setup_bun.js e o payload bun_environment.js. Atualmente, este é o único pacote Java afetado conhecido.

Vale ressaltar que o pacote Maven não foi publicado pelo PostHog. Em vez disso, foi gerado por meio de um processo automatizado do mvnpm que recompila pacotes npm como artefatos Maven. O Maven Central confirmou que todas as cópias espelhadas foram eliminadas em 25 de novembro de 2025 e que proteções adicionais estão sendo implementadas para impedir que componentes npm comprometidos sejam republicados.

Impacto global do desenvolvedor e metas de ataque

Esta última onda de ataques tem como alvo desenvolvedores do mundo todo, com o objetivo de roubar dados confidenciais, tais como:

• Chaves de API
• Credenciais da nuvem
• Tokens npm e GitHub

Ele também facilita a violação mais profunda da cadeia de suprimentos de maneira semelhante a um verme, com capacidade de autorreplicação. Esta versão do Shai-Hulud é mais furtiva, agressiva e destrutiva do que a variante inicial de setembro. Ao comprometer as contas de mantenedores do npm, os atacantes podem publicar pacotes trojanizados que instalam backdoors nas máquinas dos desenvolvedores e realizam varreduras automáticas em busca de segredos para exfiltrá-los em repositórios do GitHub.

Como o malware opera: fluxos de trabalho duplos e técnicas de ocultação.

O ataque utiliza dois fluxos de trabalho maliciosos:

• Registro de executores autohospedados: Permite a execução de comandos arbitrários sempre que uma discussão no GitHub for aberta.
• Fluxo de trabalho de coleta de segredos: Coleta credenciais sistematicamente e as envia para o GitHub.
• As principais melhorias no Shai-Hulud v2 incluem:
• Utilização do ambiente de execução Bun para ocultar a lógica principal.
• Aumento do limite de infecção de 20 para 100 pacotes
• Repositórios de exfiltração aleatórios no GitHub para evitar detecção.

Até o momento, mais de 28.000 repositórios foram afetados, demonstrando a enorme escala e o caráter furtivo da campanha.

Vulnerabilidades exploradas e mecânica da cadeia de suprimentos

Atores maliciosos têm se aproveitado de configurações incorretas de CI em fluxos de trabalho do GitHub Actions, particularmente nos gatilhos `pull_request_target` e `workflow_run`. Um único fluxo de trabalho mal configurado pode transformar um repositório em um "paciente zero", permitindo a rápida propagação de código malicioso.

O ataque teve como alvo projetos associados ao AsyncAPI, PostHog e Postman, dando continuidade a uma campanha mais ampla que começou com o ataque S1ngularity em agosto de 2025, que afetou diversos pacotes Nx no npm.

As consequências: segredos vazados e risco sistêmico

A análise da campanha mostra:

• Centenas de tokens de acesso do GitHub e credenciais de nuvem da AWS, Google Cloud e Microsoft Azure foram exfiltrados.
• Mais de 5.000 arquivos contendo segredos foram enviados para o GitHub.
• Dos 11.858 segredos únicos identificados em 4.645 repositórios, 2.298 permaneceram válidos e expostos publicamente em 24 de novembro de 2025.

Isso demonstra como um único responsável pela manutenção comprometido pode desencadear um efeito cascata, infectando milhares de aplicações subsequentes.

Recomendações para desenvolvedores

Para mitigar a exposição, os desenvolvedores devem:

• Rotacione todas as chaves de API, tokens e credenciais.
• Auditar e remover dependências comprometidas.
• Reinstale versões limpas dos pacotes.
• Reforce a segurança de ambientes CI/CD com acesso de privilégios mínimos, varredura de segredos e aplicação automatizada de políticas.

Shai-Hulud destaca que a cadeia de suprimentos de software moderna permanece altamente vulnerável. Os atacantes continuam a explorar lacunas na forma como o software de código aberto é publicado, empacotado e implantado, muitas vezes sem recorrer a vulnerabilidades de dia zero. A defesa mais eficaz exige repensar a forma como o software é construído, compartilhado e consumido.