Um ataque sofisticado à cadeia de suprimentos comprometeu centenas de pacotes npm e expôs segredos de dezenas de milhares de repositórios GitHub, com pesquisadores de segurança cibernética agora documentando como os invasores transformaram os fluxos de trabalho do GitHub Actions em armas para iniciar uma das campanhas de worm mais agressivas da memória recente.
Em 24 de novembro de 2025, às 4h11 UTC, versões maliciosas de vários SDKs PostHog JavaScript, incluindo posthog-node, posthog-js e posthog-react-native, foram publicadas no npm contendo um worm auto-replicante denominado Shai Hulud v2.
Desde então, o ataque se expandiu além do npm para o ecossistema Java/Maven, com artefatos comprometidos descobertos no Maven Central antes de serem eliminados pelas equipes de segurança.
PostHog publicado um post-mortem detalhado revelando que o ataque não se originou de credenciais comprometidas, mas da exploração de uma vulnerabilidade sutil na configuração do fluxo de trabalho do GitHub Actions.
Em 18 de novembro, um usuário agora excluído abriu uma solicitação pull que modificava um script executado por meio do gatilho pull_request_target, que executa fluxos de trabalho com o contexto de segurança do repositório de destino, em vez da bifurcação potencialmente não confiável.
O PR malicioso alterou um script de atribuição automática para exfiltrar um token de acesso pessoal de bot com amplas permissões de gravação em toda a organização GitHub do PostHog.
Em um minuto, o PR foi aberto, o fluxo de trabalho executado e o PR fechado e excluído.
Shai Hulud v2 abusa de sistemas de construção
Dias depois, em 23 de novembro, o invasor validou as credenciais roubadas e enviou um commit desanexado que modificou um fluxo de trabalho do lint para coletar todos os segredos do GitHub, incluindo os do PostHog. pacote npm token de publicação.
O ataque explorou um equívoco perigoso entre os desenvolvedores: que pull_request_target garante que a execução do código ocorra a partir do branch alvo.
Na realidade, embora a definição do fluxo de trabalho venha do alvo, o código sendo executado neste caso, um arquivo JavaScript retirado do chefe do PR era inteiramente controlado pelo invasor.
As ferramentas de análise estática sinalizaram o fluxo de trabalho vulnerável antes da fusão, mas os engenheiros rejeitaram o alerta acreditando que sua implementação era segura.
Os pacotes npm maliciosos empregam um sistema de carregamento de dois estágios. Um script de pré-instalação baixa silenciosamente o tempo de execução do Bun e executa uma carga ofuscada de 10 MB que realiza coleta agressiva de credenciais em vários vetores.
Verificando ambientes em busca de tokens, enumerando o AWS Secrets Manager em todas as regiões, extraindo segredos do GCP e do Azure e executando o TruffleHog em diretórios iniciais inteiros para encontrar credenciais codificadas.
O malware tenta escalar privilégios por meio de Baseado em Docker manipulação de sudoers, concede a si mesmo acesso root sem senha e manipula regras de DNS e firewall para permitir ataques man-in-the-middle.
Malware aproveita configurações incorretas do fluxo de trabalho
Todas as variáveis de ambiente de dados exfiltradas, segredos de nuvem e Ações do GitHub as credenciais são codificadas em base64 tripla para evitar a detecção e carregadas em repositórios nomeados aleatoriamente nas contas das vítimas marcadas com a assinatura da campanha “Sha1-Hulud: The Second Coming”.
O worm se propaga validando tokens npm roubados, buscando até 100 pacotes por mantenedor e publicando versões de patches maliciosas com cargas injetadas.
Ele realiza coleta automatizada de credenciais nos metadados do GitHub Actions, procurando por qualquer string começando com “npm_” para inicializar compromissos adicionais.
Se nenhum token válido for encontrado, a carga executa operações destrutivas de destruição de arquivos nos diretórios de usuários.
PostHog respondeu em poucas horas, revogando tokens às 9h30 UTC e publicando versões válidas.
Desde então, a empresa implementou reformas abrangentes de segurança: migrando para o modelo de editor confiável do npm, exigindo revisão da equipe de segurança para quaisquer alterações no fluxo de trabalho, adotando o pnpm 10 com proteções de script de instalação e reestruturando o gerenciamento de segredos.
Os pesquisadores de segurança recomendam ação imediata: verifique se há repositórios maliciosos nas contas do GitHub, alterne todas as credenciais que possam ter sido expostas, fixe dependências em versões válidas e implemente configurações de mínimoReleaseAge em gerenciadores de pacotes para criar um buffer antes de adotar novos lançamentos.
O ataque ressalta como as escolhas sutis de configuração de CI/CD podem criar caminhos que vão desde contribuições não confiáveis até o comprometimento da cadeia de suprimentos em todo o ecossistema.
Siga-nos emGoogle Notícias,LinkedIneXpara obter atualizações instantâneas e definir GBH como fonte preferencial emGoogle.