GhostAction: um workflow de segurança também pode ser o invasor

A campanha GhostAction usa contas comprometidas de desenvolvedores para inserir GitHub Actions maliciosos em repositórios legítimos.[1] Os arquivos identificados, security-audit.yml e github_actions_security.yml, se apresentam como auditorias de segurança, mas procuram credenciais e as enviam a uma infraestrutura externa.[1]

O problema de engenharia não é reconhecer um nome suspeito. É impedir que uma identidade autorizada a mudar código possa transformar o ambiente de integração contínua em um coletor de segredos sem passar por uma revisão independente.

O que muda para quem desenvolve

Segundo a investigação, o workflow pode rodar por acionamento manual ou por push, sem filtrar branches e tags.[1] O checkout com fetch-depth: 0 disponibiliza o histórico completo, que também entra na busca por credenciais, além dos arquivos atuais e dos segredos explicitamente referenciados pela automação.[1] Entre os alvos estão chaves de serviços de IA, nuvem e publicação de pacotes.[1]

Isso muda a unidade de análise do incidente. Não basta olhar o último commit nem perguntar se a aplicação em produção foi alterada. A revisão precisa considerar o que o runner podia ler durante a execução, quais credenciais estavam disponíveis e para onde a automação podia se conectar.

Também convém separar autenticidade de autoria e legitimidade da mudança. Uma alteração feita pela conta de um mantenedor conhecido ainda precisa de avaliação técnica. A assinatura social do projeto não substitui o controle sobre sua cadeia de entrega.

Como aplicar

Comece por um inventário de alterações em .github/workflows, incluindo forks e espelhos sob responsabilidade da equipe. A reportagem recomenda procurar os dois nomes de arquivo nas mudanças desde 31 de agosto de 2026 e remover a automação de todas as branches afetadas.[1] Use esses nomes como indicadores de triagem, não como uma lista capaz de detectar qualquer variação.

Para cada ocorrência, registre o horário das execuções e monte uma matriz: workflow, permissões, segredos acessíveis e destinos de rede. Preserve evidências antes de limpar o repositório. Revogue a credencial usada no acesso indevido e rotacione os segredos expostos, conforme a resposta recomendada na investigação.[1]

Um experimento seguro é criar um repositório descartável sem credenciais reais, inserir um marcador fictício num commit e removê-lo no seguinte. Compare uma busca apenas nos arquivos atuais com uma busca no histórico. O objetivo é verificar a cobertura da auditoria, não executar o workflow malicioso.

Depois, teste se uma alteração em workflow exige revisão de outra pessoa e se um job sem necessidade de publicação consegue acessar credenciais de publicação. O resultado desejado é uma negativa verificável, não uma regra escrita que ninguém exercitou.

Cuidados e limites

O vazamento de um token pessoal é apontado como provável caminho inicial, não como mecanismo confirmado em todos os casos.[1] As contagens de StepSecurity e Socket têm escopos diferentes e não devem ser somadas como vítimas independentes.[1] Até a publicação, não haviam sido identificados releases maliciosos de pacotes produzidos com as credenciais roubadas.[1]

A ausência desse último indicador não encerra uma investigação local. A decisão deve partir da exposição comprovada no ambiente. Reduzir permissões e duração das credenciais ajuda a limitar o dano, mas precisa acompanhar revisão de mudanças e controle de execução. Apagar um YAML é limpeza. Recuperar a confiança na entrega exige mais.

Fonte

[1] Fonte: The Hacker News | Publicação: 09/10/2026 às 16:14:28