Ataque à cadeia de suprimentos GhostAction compromete mais de 340 repositórios do GitHub via duas contas de mantenedores

Uma nova onda do ataque à cadeia de suprimentos GhostAction comprometeu duas contas conhecidas de mantenedores Open Source em 8 de outubro de 2026 e utilizou o acesso de push dessas contas para plantar um workflow malicioso do GitHub Actions em mais de 340 repositórios em questão de minutos, de acordo com pesquisa publicada pela StepSecurity.

A primeira conta pertencia ao desenvolvedor do game engine pyxel, um projeto com cerca de 18.400 estrelas no GitHub. Ela foi usada para fazer push do workflow malicioso em 27 repositórios entre 13h20 e 13h44 UTC. Oito horas depois, uma segunda conta comprometida — pertencente ao autor original da biblioteca Open Source athenadriver, da Uber — fez push do mesmo workflow em 318 repositórios, incluindo 39 projetos-fonte e 279 forks, em uma janela de apenas 16 minutos. O acesso chegou até a própria organização da Uber no GitHub antes que a empresa pudesse intervir.

Workflows do GitHub Actions tornaram-se um alvo preferido para atacantes de cadeia de suprimentos porque uma única conta de mantenedor comprometida pode silenciosamente injetar automação maliciosa em todos os repositórios nos quais ela tem permissão de escrita — e essa automação passa a rodar com a confiança e as credenciais já configuradas no projeto. A campanha GhostAction original, identificada em setembro de 2025, roubou mais de 3.300 secrets de 817 repositórios vinculados a 327 desenvolvedores. Esta segunda onda reutilizou o mesmo playbook em escala maior e contra alvos de maior visibilidade.

Os arquivos injetados — chamados security-audit.yml e uma variante mais antiga denominada github_actions_security.yml — foram disfarçados como rotinas de varredura de segurança. Uma vez acionados, eles vasculhavam tanto a working tree quanto o histórico completo do git, incluindo arquivos deletados, em busca de 13 categorias de credenciais: chaves de acesso e tokens de sessão da AWS, API keys da Anthropic, OpenAI e OpenRouter, tokens do GitHub e do GitLab, chaves do Google e do Firebase, tokens de bot do Slack e credenciais do SendGrid. Também coletavam secrets específicos já configurados nos workflows de cada repositório, como tokens de publicação do PyPI e do Cargo. Tudo que era encontrado era enviado em texto puro para um servidor de comando e controle hardcoded.

Em 9 de outubro, a StepSecurity encontrou 378 repositórios ainda com o workflow malicioso ativo em seu branch padrão, com evidências confirmadas de que secrets nomeados haviam sido exfiltrados de pelo menos 88 deles. Nenhuma publicação maliciosa de pacotes vinculada às credenciais de publicação roubadas havia surgido até o momento em que a pesquisa foi divulgada, mas a empresa alertou que qualquer repositório com uma execução completa do workflow deve ser tratado como uma violação confirmada.

O incidente é um lembrete de que a confiança no ecossistema Open Source passa por contas individuais de mantenedores, e não por organizações: o próprio repositório da Uber foi afetado não porque a empresa foi alvo direto, mas porque as credenciais comprometidas de um colaborador externo chegaram até ele. A StepSecurity orienta todos que mantêm projetos afetados a rotacionar toda credencial já commitada em qualquer branch — já que a etapa de mineração de histórico do ataque lê secrets deletados há muito tempo —, revogar as sessões comprometidas, remover o workflow de todos os branches e forks, e exigir Code Review via Pull Request antes de qualquer alteração no diretório .github/workflows do repositório.