Ataques Shai Hulud Persistem Através de Vulnerabilidades no GitHub Actions

Apenas um dia se passou desde que o segundo ataque à cadeia de suprimentos Shai Hulud se espalhou pelo ecossistema, e novos utilizadores e organizações continuam a ser comprometidos a cada hora. À medida que analisamos as consequências, começamos a descobrir o vetor de infeção inicial que os atacantes usaram para comprometer grandes projetos como AsyncAPI, PostHog e Postman, e está ficando claro que ainda não vimos toda a extensão dessa campanha. Ao explorar vulnerabilidades sutis, mas poderosas, nos fluxos de trabalho do GitHub Actions, os atacantes demonstraram uma evolução preocupante nos seus métodos de entrega. Isso é um forte lembrete de que as nossas defesas devem evoluir com a mesma rapidez e que a segurança do ecossistema de código aberto depende do fortalecimento contínuo da infraestrutura que muitas vezes consideramos garantida.

Cronologia da Campanha Shai-Hulud

• 27 de agosto - Divulgamos o nosso relatório detalhando a campanha S1ngularity, que tem como alvo vários pacotes nx no npm.  
• 16 de setembro - O invasor ataca novamente, lançando a primeira onda dos ataques Shai-Hulud.  
• 18 de setembro — Publicamos uma análise complementar, aprofundando as peculiaridades técnicas da campanha e o comportamento inicial da carga útil.  
• 24 de novembro — Ocorre um segundo ataque, apelidado de «Segunda Vinda» pelos invasores, programado para ocorrer pouco antes do prazo final da npm para revogar os tokens antigos.
• 25 de novembro — Descobrimos o vetor de entrada inicial dos invasores por meio de fluxos de trabalho vulneráveis do GitHub Actions em projetos como AsyncAPI, PostHog e Postman.
  

Uma rápida atualização

Desde a violação da Nx e o ataque Shai Hulud, sabemos que o invasor tem abusado dos fluxos de trabalho do GitHub Actions para extrair dados através de links do webhook.site. Em incidentes anteriores, o método era simples. O invasor plantava um backdoor deliberado dentro de um ficheiro de fluxo de trabalho, e esse backdoor transmitia silenciosamente informações confidenciais, incluindo credenciais, de volta para um terminal controlado pelo invasor.

O que estamos a ver na última onda da campanha Shai Hulud é mais avançado. Em vez de inserir backdoors diretamente, os atacantes agora estão a explorar vulnerabilidades nos fluxos de trabalho existentes do GitHub Actions para executar o seu ataque. Essa mudança na técnica foi o que permitiu que eles comprometessem projetos como AsyncAPI, PostHog e Postman no ataque Shai-Hulud de ontem.

A nossa investigação começou quando notámos vários uploads suspeitos para o NPM ligados a nomes de utilizador inesperados, como «codespace» e «runner». Esses uploads imediatamente se destacaram como anomalias, e uma análise mais profunda mostrou que todos eles provavelmente foram inseridos manualmente pelo invasor através da exploração do GitHub Actions. Mais tarde, fomos notificados por terceiros sobre uma extensão OpenVSX maliciosa relacionada com um padrão semelhante. Essa descoberta confirmou que os atacantes evoluíram os seus métodos e agora estão a aproveitar as configurações incorretas de CI como parte da sua cadeia de invasão.

Como o invasor usou as vulnerabilidades do GitHub Actions

Os fluxos de trabalho do GitHub Actions são scripts automatizados que são executados dentro de um repositório para lidar com tarefas como testes, compilação, publicação ou gestão de pull requests. Eles são poderosos e flexíveis, mas esse poder acarreta riscos, especialmente quando os fluxos de trabalho são configurados sem uma compreensão completa de como eles executam código não confiável.

Certos gatilhos de fluxo de trabalho, incluindo alvo_da_solicitação_de_pull e execução do fluxo de trabalho, pode tornar-se perigoso quando mal configurado. Foi exatamente isso que aconteceu no caso do PostHog, como mostra a captura de ecrã. A questão foi inicialmente trazida à atenção do público por Adnan Khan, um investigador de segurança que destacou o fluxo de trabalho vulnerável numa publicação no X. O ataque foi provavelmente causado por uma vulnerabilidade dentro do .github/workflows/auto-assign-reviewers.yml fluxo de trabalho. Esse ficheiro utilizava o arriscado alvo_da_solicitação_de_pull acionar de forma a permitir que o código fornecido por qualquer nova solicitação de pull fosse executado durante a execução da CI. A vulnerabilidade foi introduzida pela primeira vez em 11 de setembro de 2025 por meio de uma solicitação de pull mesclada, onde permaneceu disponível até o ataque Shai Hulud. No total, o problema esteve presente por 74 dias antes de ser explorado pelo invasor.

Um padrão semelhante aparece no repositório AsyncAPI. Descobrimos que o seu .github/workflows/auto-changeset.yml O ficheiro continha uma configuração vulnerável adicionada em 9 de setembro de 2025. A equipa da AsyncAPI removeu o ficheiro seguindo a nossa recomendação, mas a configuração ficou disponível por tempo suficiente para que o invasor incluísse este projeto na campanha.

Vale a pena notar que um desses projetos já estava a utilizar uma ferramenta de verificação de relações públicas, mas mesmo assim não conseguiu detetar as vulnerabilidades ocultas nos fluxos de trabalho do GitHub Actions. No caso do PostHog, o GitHub alertou sobre a vulnerabilidade, mas esse aviso não foi atendido. Isso destaca a necessidade de ferramentas de segurança que possam compreender e sinalizar problemas em uma ampla gama de sistemas e linguagens, incluindo vulnerabilidades de configuração de CI. Uma vez que um invasor identifica um fluxo de trabalho explorável em um projeto, essa única fraqueza pode servir como ponto de apoio para um ataque que se espalha em uma escala nunca vista antes, como demonstrado pelo worm Shai Hulud.

O que deve saber e as medidas a tomar

À medida que essas ameaças continuam a evoluir, torna-se cada vez mais importante entender como as vulnerabilidades nos fluxos de trabalho do GitHub Actions podem expor não apenas o seu próprio projeto, mas todos os projetos e utilizadores conectados a ele. Uma única configuração incorreta pode transformar um repositório no paciente zero de um ataque de rápida propagação, dando a um adversário a capacidade de enviar código malicioso por meio de pipelines automatizados dos quais você depende todos os dias. Os programadores só podem se defender contra o que conhecem, portanto, é importante estar ciente de padrões de fluxo de trabalho perigosos, como alvo_da_solicitação_de_pull e execução do fluxo de trabalho é essencial. Outra opção é usar uma plataforma de segurança como Aikido verifica automaticamente repositórios e pull requests recebidos em busca desses tipos de vulnerabilidades.

É igualmente importante estar ciente das vulnerabilidades nas dependências que instala. Mesmo que os seus próprios fluxos de trabalho sejam seguros, pacotes comprometidos a montante ainda podem representar um risco. É aqui que SCA Aikido, o Intel Vulnerability Database e os insights do Package Health são especialmente úteis, ajudando as equipas a detectar problemas antecipadamente e a compreender se as bibliotecas nas quais confiam mostram sinais de comprometimento ou atividade suspeita.

Por fim, ter uma ferramenta capaz de bloquear malware em tempo real assim que ele aparece pode evitar uma infecção grave. Essa é a ideia por trás Aikido Chain, uma ferramenta gratuita que envolve o npm e usa IA e pesquisadores humanos de malware para detectar e bloquear os riscos mais recentes da cadeia de suprimentos antes que eles entrem no seu ambiente.

‍