GhostAction: um workflow com nome de auditoria ainda é código com acesso a segredos

A GitGuardian identificou uma expansão da campanha GhostAction com cerca de 1.900 contas GitHub comprometidas e mais de 30 mil repositórios visados.[4] A operação tentou extrair 3.174 segredos do CI de repositórios públicos, mas esse número não comprova que todas as credenciais foram obtidas.[4] O mecanismo usa credenciais e tokens pessoais roubados para inserir workflows com nomes que parecem rotinas de segurança.[4]

O que muda para quem desenvolve

Os alvos incluem credenciais de nuvem, tokens de registries e chaves de provedores de IA.[4] O payload também passou a procurar segredos no histórico Git, preservando contexto para relacionar identificadores AWS às respectivas chaves secretas.[4]

A consequência de engenharia é tratar mudanças em automação como alterações em uma fronteira de confiança. Um arquivo pequeno, colocado na pasta esperada e com um nome tranquilizador, ainda precisa de revisão proporcional ao que consegue acessar. A finalidade declarada do workflow não deve definir suas permissões.

Também convém separar três eventos: acesso indevido à conta, execução de código no CI e uso de uma credencial no serviço de destino. Conter um deles não demonstra que os outros não aconteceram. Essa separação ajuda a distribuir a investigação sem dar o incidente por encerrado cedo demais.

Como aplicar

Revise alterações recentes em workflows e a atividade das identidades com permissão de escrita. Compare cada mudança com uma solicitação conhecida e com o responsável pela automação. Dê atenção especial a novas etapas que leem segredos, consultam histórico ou enviam dados para destinos externos.

Em uma cópia controlada do repositório, faça um exercício de revisão: escolha um workflow legítimo e documente quais credenciais ele realmente precisa. Depois compare essa lista com o acesso configurado. O resultado esperado é uma justificativa por permissão, não um novo scanner executando com acesso irrestrito.

Se houver exposição, revogue e substitua os segredos afetados e investigue seu uso nos serviços de destino. Essa é a orientação prática apresentada no relato.[4] Coordene a rotação com os consumidores para evitar que a contenção vire uma sequência de falhas silenciosas. Registre quais integrações foram atualizadas e quais ainda dependem da credencial antiga.

Cuidados e limites

Segundo a GitGuardian, o GitHub começou a impedir a execução do workflow malicioso em 09/10/2026, e ondas posteriores de 10 e 12/10 não conseguiram extrair segredos por esse mecanismo.[4] Isso não prova que o acesso indevido às contas tenha sido eliminado nem desfaz exposições anteriores.[4]

Parte das vítimas já havia aparecido em campanhas anteriores, sugerindo persistência de credenciais não revogadas.[4] A lição não é desconfiar de toda automação. É exigir identidade, escopo e revisão para ela. Uma ferramenta chamada “auditoria” não deve ganhar um passe livre para levar as chaves da casa.

Fonte

[4] Fonte: The Hacker News