Apenas um dia se passou desde que o segundo ataque à cadeia de suprimentos Shai Hulud se espalhou pelo ecossistema, e novos usuários e organizações ainda estão sendo comprometidos a cada hora. Enquanto analisamos as consequências, estamos começando a descobrir o vetor de infecção inicial que os atacantes usaram para comprometer grandes projetos como AsyncAPI, PostHog e Postman, e está ficando claro que ainda não vimos a extensão total desta campanha. Ao explorar vulnerabilidades sutis, mas poderosas, nos fluxos de trabalho do GitHub Actions, os atacantes demonstraram uma evolução preocupante em seus métodos de entrega. Este é um forte lembrete de que nossas defesas devem evoluir tão rapidamente e que a segurança do ecossistema de código aberto depende do endurecimento contínuo da infraestrutura que muitas vezes consideramos garantida.
Linha do tempo da Campanha Shai-Hulud
- 27 de agosto - Lançamos nosso relatório detalhando a campanha S1ngularity que visava vários pacotes nx no npm.
- 16 de setembro - O atacante ataca novamente, lançando a primeira onda dos ataques Shai-Hulud.
- 18 de setembro - Publicamos uma análise de acompanhamento, aprofundando-nos nas peculiaridades técnicas da campanha e no comportamento inicial do payload.
- 24 de novembro - Um segundo ataque ocorre, apelidado de “Segunda Vinda” pelos atacantes, cronometrado pouco antes do prazo do npm para revogar tokens antigos.
- 25 de novembro - Descobrimos o vetor de entrada inicial dos atacantes através de workflows vulneráveis do GitHub Actions em projetos como AsyncAPI, PostHog e Postman.
Uma breve recapitulação
Desde o ataque Nx e o ataque Shai Hulud, sabemos que o atacante tem abusado dos workflows do GitHub Actions para exfiltrar dados através de links do webhook.site. Em incidentes anteriores, o método era direto. O atacante plantou um backdoor deliberado dentro de um arquivo de workflow, e esse backdoor transmitia silenciosamente informações sensíveis, incluindo credenciais, de volta para um endpoint controlado pelo atacante.
O que estamos vendo na última onda da campanha Shai Hulud é mais avançado. Em vez de inserir backdoors diretamente, os atacantes agora estão explorando vulnerabilidades em workflows existentes do GitHub Actions para executar seu ataque. Essa mudança na técnica foi o que lhes permitiu comprometer projetos como AsyncAPI, PostHog e Postman no ataque Shai-Hulud de ontem.
Nossa investigação começou quando notamos vários uploads suspeitos para o NPM vinculados a nomes de usuário inesperados, como “codespace” e “runner.” Esses uploads imediatamente se destacaram como anomalias, e uma análise mais aprofundada mostrou que todos foram provavelmente semeados manualmente pelo atacante através da exploração do GitHub Actions. Fomos posteriormente notificados por terceiros sobre uma extensão OpenVSX maliciosa relacionada com um padrão semelhante. Essa descoberta confirmou que os atacantes evoluíram seus métodos e agora estão alavancando as más configurações de CI como parte de sua cadeia de intrusão.
Como o atacante usou as vulnerabilidades do GitHub Actions
Workflows do GitHub Actions são scripts automatizados que são executados dentro de um repositório para lidar com tarefas como testes, construção, publicação ou gerenciamento de pull requests. Eles são poderosos e flexíveis, mas esse poder vem com riscos, especialmente quando os workflows são configurados sem uma compreensão completa de como eles executam código não confiável.
Certos gatilhos de workflow, incluindo pull_request_target e workflow_run, podem se tornar perigosos quando mal configurados. Isso é exatamente o que aconteceu no caso do PostHog, como mostrado na captura de tela. O problema foi primeiramente levado à atenção geral por Adnan Khan, um pesquisador de segurança que destacou o workflow vulnerável em uma publicação no X. O ataque foi provavelmente causado por uma vulnerabilidade dentro do .github/workflows/auto-assign-reviewers.yml workflow. Esse arquivo usava o arriscado pull_request_target gatilho de uma forma que permitia que o código fornecido por qualquer novo pull request fosse executado durante a execução do CI. A vulnerabilidade foi introduzida pela primeira vez em 11 de setembro de 2025 através de um pull request mesclado, onde permaneceu disponível até o ataque Shai Hulud. No total, o problema esteve presente por 74 dias antes que o atacante o explorasse.
Um padrão semelhante aparece no repositório AsyncAPI. Descobrimos que o arquivo deles .github/workflows/auto-changeset.yml continha uma configuração vulnerável adicionada em 9 de setembro de 2025. A equipe AsyncAPI removeu o arquivo desde então, seguindo nossa recomendação, mas a configuração esteve disponível por tempo suficiente para o atacante incluir este projeto na campanha.
Vale ressaltar que um desses projetos já estava usando uma ferramenta de varredura de PRs, mas ainda assim falhou em detectar as vulnerabilidades ocultas nos workflows do GitHub Actions. No caso do PostHog, o GitHub alertou sobre a vulnerabilidade, mas o aviso não foi atendido. Isso destaca a necessidade de ferramentas de segurança que possam entender e sinalizar problemas em uma ampla gama de sistemas e linguagens, incluindo vulnerabilidades de configuração de CI. Uma vez que um atacante identifica um workflow explorável em um projeto, essa única fraqueza pode servir como um ponto de apoio para um ataque que se espalha em uma escala que nunca vimos antes, como demonstrado pelo worm Shai Hulud.
O que você deve saber e ações a serem tomadas
À medida que essas ameaças continuam a evoluir, torna-se cada vez mais importante entender como as vulnerabilidades nos workflows do GitHub Actions podem expor não apenas seu próprio projeto, mas todos os projetos e usuários conectados a ele. Uma única má configuração pode transformar um repositório em um paciente zero para um ataque de rápida propagação, dando a um adversário a capacidade de enviar código malicioso através de pipelines automatizados nos quais você confia todos os dias. Os desenvolvedores só podem se defender contra o que conhecem, então a conscientização sobre padrões de workflow perigosos, como pull_request_target e workflow_run é essencial. Outra opção é usar uma plataforma de segurança como o Aikido que verifica automaticamente repositórios e pull requests de entrada em busca desses tipos de vulnerabilidades.
É igualmente importante permanecer ciente das vulnerabilidades nas dependências que você instala. Mesmo que seus próprios workflows sejam seguros, pacotes comprometidos a montante ainda podem introduzir riscos. É aqui que as capacidades de SCA do Aikido, o Intel Vulnerability Database e os insights de Package Health são especialmente úteis, ajudando as equipes a identificar problemas precocemente e a entender se as bibliotecas nas quais confiam mostram sinais de comprometimento ou atividade suspeita.
Finalmente, ter uma ferramenta que possa parar malware em tempo real assim que ele aparece pode prevenir uma infecção séria. Essa é a ideia por trás do Aikido Safe Chain, uma ferramenta gratuita que se integra ao npm e usa tanto IA quanto pesquisadores humanos de malware para detectar e bloquear os mais recentes riscos da cadeia de suprimentos antes que entrem em seu ambiente.
