O ecossistema JavaScript/npm enfrenta um novo marco em ameaças à cadeia de suprimentos com o ressurgimento do Shai-Hulud 2.0 em 24 de novembro de 2025. O worm autopropagável tem como alvo específico os mantenedores de código aberto e os pacotes que eles publicam. Essa nova variante marca uma mudança de pacotes maliciosos isolados para um mecanismo de infeção coordenado e automatizado.
O impacto já é grave. Centenas de pacotes npm e dezenas de milhares de repositórios GitHub foram afetados, criando um «raio de ação» sem precedentes para um ataque à cadeia de suprimentos JavaScript. Para os leitores familiarizados com a análiseOPSWATsobre o Shai-Hulud 1.0, a versão 2.0 expande drasticamente as capacidades e a escala operacional do worm: execução mais precoce, propagação mais ampla e maior resistência à remediação padrão, elevando-o de uma ameaça preocupante para um incidente em nível de ecossistema completo.
Shai-Hulud 2.0 Informações rápidas
- Worm autopropagável: Shai-Hulud 2.0 rouba credenciais do GitHub, reempacota-se e republica-se em todo o portfólio npm de um mantenedor.
- Propagação massiva:mais de 700 pacotes npm infetados, mais de 25.000 repositórios GitHub, 500 mantenedores afetados; mais de 1.000 novos repositórios adicionados a cada 30 minutos (Wiz).
- Impacto entre ecossistemas: Também observado no Maven/Java através do espelhamento automatizado do npm para o Maven.
- Principais riscos: exposição a CI/CD, segredos comprometidos, execução no momento da instalação e registos corrompidos.
- Defesa: precisão da SBOM, verificação da proveniência, monitoramento do tempo de execução e higiene rigorosa de tokens/segredos.
Âmbito e escalonamento: qual é a extensão dos danos?
A escala e a velocidade da propagação do Shai-Hulud 2.0 superaram tudo o que se viu em incidentes recentes na cadeia de suprimentos. O que começou como um comprometimento direcionado ao npm rapidamente se transformou numa infecção sistémica e multiplataforma, afetando milhares de projetos e centenas de mantenedores.
Ao contrário do malware npm típico, que geralmente envolve um único pacote trojanizado, o Shai-Hulud 2.0 se comporta como um worm. Depois de comprometer um programador, ele rouba as credenciais do GitHub, reempacota-se e republica-se em todo o conjunto de pacotes do mantenedor, transformando cada vítima num novo ponto de distribuição. O resultado é uma propagação rápida e exponencial por todo o ecossistema.
Pacotes comprometidos
Centenas de pacotes npm foram comprometidos. Entre eles estão projetos de grande visibilidade mantidos por organizações bem estabelecidas, amplificando a exposição a jusante.
Propagação rápida e exponencial
O worm foi observado a gerar mais de 1.000 novos repositórios GitHub maliciosos a cada 30 minutos (Wiz), alimentado pela publicação automatizada a partir de credenciais roubadas. Cada nova vítima torna-se um nó de propagação, multiplicando o impacto total a cada ciclo.
Segredos revelados
O componente de roubo de credenciais do Shai-Hulud 2.0 está a revelar-se especialmente prejudicial. Os segredos verificados que vazaram incluem mais de 1.500 credenciais e tokens abrangendo as principais plataformas – GitHub, AWS, Google Cloud e Azure.
Este volume de tokens sensíveis representa um compromisso amplo e multicloud com potencial para exploração de longo prazo.
Esforços de remediação
Felizmente, vários mantenedores de alto perfil, como Zapier, PostHog e Postman, já recuperaram o controlo dos seus pacotes. As versões maliciosas foram removidas do npm, e muitos repositórios afetados estão a ser recuperados ou limpos.
No entanto, o incidente ainda está em evolução. Mesmo com uma correção rápida, as organizações devem continuar a monitorar a integridade das dependências, os pipelines de CI e as contas do GitHub em busca de sinais de mais vazamentos de credenciais ou republicações automatizadas.
Impacto entre ecossistemas: npm → Maven/Java
Notavelmente, essa onda também impactou outros ecossistemas, como Maven/Java, por meio da conversão automatizada de artefatos npm para Maven (JFrog).
-
Embora o npm continue sendo o alvo principal do Shai-Hulud 2.0, essa onda demonstrou o risco de propagação entre ecossistemas, especificamente em projetos Java/Maven. Pesquisadores de segurança identificaram o artefato Maven malicioso:
org.mvnpm:posthog-node:4.18.1que contém a mesma carga útil (setup_bun.jsebun_ambiente.js) encontrados em pacotes npm comprometidos (Notícias sobre hackers) .
- Mecanismo: Ferramentas de ponte automatizadas reconstruem pacotes npm como artefactos Maven para projetos Java. Equipas que não utilizam diretamente o Node.js podem ficar expostas se os seus projetos dependerem desses artefactos espelhados.
Isso demonstra o risco independente do ecossistema de ataques à cadeia de suprimentos. Mesmo projetos que não utilizam diretamente o npm podem herdar riscos por meio de ferramentas automatizadas.
O Shai-Hulud 2.0 demonstra que os worms modernos da cadeia de abastecimento são ameaças multietápicas e sensíveis ao ambiente: eles adaptam-se às máquinas dos programadores e aos pipelines de CI/CD, recolhem credenciais como carga útil e mecanismo de propagação e incluem comportamentos de fallback para garantir a propagação ou o impacto destrutivo. A detecção requer a monitorização do comportamento em tempo de execução em todas as etapas, não apenas a análise estática do código.
Mecânica técnica: como funciona o worm
| Palco | O que acontece |
|---|---|
| 1. Acesso inicial e implementação | Os invasores aproveitam contas comprometidas de mantenedores do npm para distribuir pacotes contendo setup_bun.js e bun_ambiente.js, executado automaticamente através de um pré-instalar conecte máquinas de desenvolvedores e pipelines de CI/CD. |
| 2. Inicialização furtiva do tempo de execução | O carregador deteta o ambiente do host, inicializa o tempo de execução do Bun e executa a carga útil silenciosamente em segundo plano para que as instalações pareçam normais. |
| 3. Impressão digital do ambiente e escalonamento de privilégios | A carga útil identifica plataformas CI, tenta obter acesso root sem senha através do Docker em executores Linux e pode modificar regras DNS ou iptables para controlar fluxos de rede. |
| 4. Recolha de credenciais e segredos | A carga útil recolhe variáveis de ambiente e chaves de nuvem, executa o TruffleHog para descoberta de segredos locais, extrai credenciais AWS/Azure/GCP e injeta fluxos de trabalho temporários para extrair segredos do GitHub. |
| 5. Exfiltração e persistência | Os dados roubados são codificados em base64 tripla e carregados para um novo repositório na conta da vítima, enquanto a persistência é estabelecida por meio de um executor e fluxo de trabalho maliciosos auto-hospedados. |
| 6. Propagação do worm (replicação) | Usando tokens npm roubados, o worm clona os pacotes da vítima, injeta ficheiros maliciosos e hooks, atualiza as versões e os republica para se espalhar de forma autónoma. |
| 7. Recurso destrutivo | Se não for possível recolher credenciais, o worm aciona uma rotina destrutiva que apaga completamente o diretório pessoal do utilizador. |
Riscos de CI/CD destacados pelo incidente da PostHog
A violação da PostHog demonstra a sutileza da exposição de CI/CD:
- Pull requests maliciosos aproveitaram o pull_request_target no GitHub Actions.
- Um bot PAT foi exfiltrado, o que permitiu a publicação de SDKs npm trojanizados.
Os fluxos de trabalho de CI/CD, mesmo os automatizados, são superfícies de ataque de alto risco. Restrinja scripts, minimize a exposição de tokens e imponha credenciais de curta duração.
Limitações das defesas tradicionais
- A fixação de dependências pode falhar devido a dependências transitivas.
- Os scanners SCA estáticos não conseguem detetar código trojanizado recém-publicado sob nomes de pacotes legítimos.
- O uso indevido de tokens por meio de pipelines de CI/CD significa que até mesmo repositórios internos estão em risco.
Como usar o SBOM e Supply Chain como defesa
As ferramentas SBOM e de cadeia de abastecimento podem fornecer:
- Transparência das dependências: rastreia dependências diretas e transitivas com metadados de versão e mantenedor.
- Verificação da proveniência: identifica alterações inesperadas na embalagem ou mantenedores desconhecidos.
- Monitorização de credenciais e segredos: deteta tentativas de exfiltração ou tokens utilizados indevidamente.
- Informações comportamentais: monitora o acesso a recursos ou padrões de execução incomuns durante as instalações.
Embora não seja uma solução milagrosa, combinar SBOM com monitoramento contínuo fortalece as defesas contra ataques do tipo worm.
OPSWAT e MetaDefender Software Supply ChainChain™
A tecnologia OPSWAT analisa o repositório de código-fonte e deteta o pacote malicioso npm sha1-hulud.
MetaDefender Software Supply Chain oferece uma visão mais completa e detecta o pacote sha1-hulud comprometido.
O Metascan Multiscanning adiciona camadas de defesa para detetar malware:
Ações imediatas recomendadas
- Rote as credenciais: PATs do GitHub, tokens npm, chaves SSH, credenciais na nuvem; habilite a autenticação multifator (MFA).
- Remova pacotes comprometidos: limpe o cache do npm, node_modules e fixe versões conhecidas como limpas.
- Auditoria do GitHub e CI/CD: procure novos repositórios, fluxos de trabalho e commits suspeitos.
- Fortaleça os pipelines: restrinja os scripts de ciclo de vida, limite o acesso à rede externa e minimize o escopo dos tokens.
- Monitorização contínua: trate as dependências e crie pipelines como parte da superfície de ataque crítica.
Principais conclusões
As ameaças à cadeia de abastecimento são independentes do ecossistema
O impacto do Shai-Hulud 2.0 no Maven/Java através da ponte npm-to-Maven mostra que os ataques à cadeia de suprimentos podem ultrapassar as fronteiras da linguagem e do ecossistema. Mesmo projetos que não utilizam diretamente o npm podem ficar expostos se forem utilizadas ferramentas de ponte automatizadas.
A higiene das credenciais é fundamental
Tokens roubados (GitHub, npm, nuvem) permitem a propagação e o acesso a ambientes confidenciais. Use tokens de curta duração e com escopo limitado, imponha a autenticação multifatorial (MFA) e alterne as credenciais imediatamente após qualquer suspeita de comprometimento. Use ferramentas automatizadas de verificação de segredos para acelerar o processo.
Supply Chain holística Supply Chain é obrigatória
Depender exclusivamente da análise estática SCA ou das versões fixas é insuficiente. Combine visibilidade SBOM, análise múltipla de malware e proteção de tokens/segredos para reduzir a exposição em todos os ecossistemas. Explore MetaDefender Software Supply Chain
Pronto para proteger a sua cadeia de fornecimento de software e prevenir ciberataques com soluções personalizadas e perfeitamente integradas?
