Uma campanha de ataques à cadeia de suprimentos de software, identificada como GhostAction, colocou milhares de projetos hospedados no GitHub em risco. A operação utiliza contas de desenvolvedores comprometidas para inserir fluxos de trabalho maliciosos no GitHub Actions, ferramenta responsável por automatizar tarefas como testes, compilação e publicação de aplicações. Segundo a análise atribuída à GitGuardian em outubro de 2026, os invasores comprometeram aproximadamente 1.900 contas e miraram mais de 30 mil repositórios, ampliando o risco de exposição de credenciais e de abuso de infraestruturas de desenvolvimento.
O diferencial dessa campanha é a exploração de acessos legítimos. Em vez de depender exclusivamente de falhas no código das aplicações, os criminosos utilizam tokens roubados para alterar arquivos de automação e executar tarefas destinadas a coletar informações confidenciais. Um arquivo com nome aparentemente inofensivo, como security-audit.yml, pode esconder instruções para procurar credenciais e enviá-las a servidores controlados pelos invasores.
As consequências podem ultrapassar o GitHub. Entre os alvos estão chaves da AWS, tokens de publicação do npm e do PyPI, credenciais do DockerHub e chaves de API de serviços de inteligência artificial. Para desenvolvedores, administradores de sistemas e equipes de DevOps, o caso demonstra por que proteger apenas o código-fonte não é suficiente: também é necessário controlar rigorosamente as permissões, as credenciais e as automações que fazem parte do processo de desenvolvimento.
Como a campanha GhostAction evoluiu e comprometeu contas do GitHub
A GhostAction foi identificada inicialmente em setembro de 2025, quando pesquisadores documentaram uma operação voltada ao roubo de segredos em ambientes de desenvolvimento. A campanha chamou a atenção por explorar o GitHub Actions como meio de acessar informações confidenciais e ampliar o alcance de um comprometimento inicial.
Em outubro de 2026, a operação voltou a ganhar destaque com uma nova onda de ataques. De acordo com os números atribuídos à investigação da GitGuardian, os invasores comprometeram cerca de 1.900 contas e miraram mais de 30 mil repositórios. A análise também identificou tentativas de coleta de credenciais em diferentes projetos, evidenciando a escala que esse tipo de ataque pode alcançar quando os criminosos conseguem controlar contas legítimas.
O principal vetor de entrada envolve Tokens de Acesso Pessoal (PATs) roubados e informações obtidas por infostealers. Esses programas maliciosos extraem dados de dispositivos comprometidos, incluindo credenciais armazenadas em navegadores, arquivos locais e ferramentas de desenvolvimento.
Com um token que tenha permissões suficientes, o invasor pode modificar repositórios sem precisar explorar diretamente uma vulnerabilidade no GitHub. Se a conta comprometida tiver acesso a diversos projetos, o mesmo acesso pode ser utilizado para introduzir alterações maliciosas em vários deles.
Esse cenário transforma o comprometimento de uma única conta em um risco para toda a cadeia de suprimentos de software. Bibliotecas, aplicações e ferramentas mantidas por desenvolvedores afetados podem ficar expostas a alterações não autorizadas, dependendo das permissões e dos controles existentes.
O disfarce dos arquivos maliciosos no GitHub Actions
Um dos elementos associados à campanha é a inclusão de arquivos de automação com nomes que aparentam indicar atividades legítimas de segurança, como security-audit.yml.
Esses arquivos ficam normalmente no diretório .github/workflows/, utilizado pelo GitHub Actions para identificar as definições dos fluxos de trabalho. Quando um arquivo malicioso é adicionado e executado, ele pode aproveitar as permissões concedidas à automação para acessar informações disponíveis durante o processo.
O nome do arquivo, isoladamente, não comprova uma infecção. A investigação deve considerar o conteúdo do código, os gatilhos de execução, as permissões solicitadas e os destinos de rede utilizados.
A principal dificuldade é que uma alteração aparentemente rotineira pode passar despercebida durante uma revisão superficial. Por isso, equipes de desenvolvimento precisam examinar não apenas quem realizou o commit, mas também o que foi alterado e quais ações serão executadas automaticamente.
Como o ataque utiliza o GitHub Actions para roubar segredos
O GitHub Actions permite executar tarefas automatizadas em resposta a eventos como commits, solicitações de integração e publicações de versões. Para isso, os fluxos podem receber variáveis, tokens e segredos configurados no repositório ou na organização.
Essa integração é útil, mas cria uma superfície de ataque quando uma automação maliciosa consegue executar comandos com permissões excessivas. Dependendo da configuração, o processo pode acessar credenciais destinadas à publicação de pacotes, à implantação de aplicações ou à administração de recursos em nuvem.
Uma das evoluções técnicas atribuídas às variantes recentes da GhostAction é a varredura do histórico do Git por meio de expressões regulares (regex). Essa abordagem permite procurar sequências que correspondam a formatos conhecidos de tokens e chaves de acesso.
O perigo está no fato de que uma credencial removida do código atual pode continuar registrada em commits antigos. Apagar o arquivo que continha a chave não invalida a credencial, nem garante que ela tenha desaparecido do histórico do projeto.
Quando o fluxo tem acesso ao histórico completo do repositório, a busca pode revelar informações que os responsáveis acreditavam ter eliminado. A mesma lógica se aplica a outros dados sensíveis que tenham sido incorporados acidentalmente ao código-fonte.
Quais credenciais podem ser expostas
O alcance da coleta depende dos segredos disponíveis e das permissões concedidas à automação. Entre os principais alvos estão:
- AWS: chaves de acesso que podem permitir operações em serviços de nuvem, de acordo com as permissões associadas à identidade comprometida.
- GitHub e GitLab: tokens que podem facilitar novas alterações em projetos ou ampliar o acesso a outros repositórios.
- npm e PyPI: credenciais de publicação que podem ser utilizadas para distribuir versões adulteradas de pacotes.
- DockerHub: acessos que podem permitir a publicação ou alteração de imagens de contêineres.
- Plataformas de inteligência artificial: chaves de API que podem viabilizar o uso indevido de serviços, gerar cobranças ou expor funcionalidades privadas.
Uma credencial roubada pode servir como ponto de partida para novos ataques. Por exemplo, um token de publicação comprometido pode permitir a distribuição de uma biblioteca maliciosa, enquanto uma chave de nuvem com permissões amplas pode abrir caminho para recursos internos de uma organização.
Isso não significa que todos os repositórios atingidos tenham sofrido o roubo efetivo de todas essas credenciais. O impacto depende do que estava acessível durante a execução do fluxo e dos mecanismos de proteção implementados.
Por que remover o arquivo malicioso não resolve tudo
Um dos principais riscos da campanha é o recomprometimento causado pela reutilização de credenciais antigas. Se um desenvolvedor remove o fluxo malicioso, mas mantém ativos os tokens anteriormente expostos, os invasores podem continuar utilizando essas credenciais.
Por isso, a resposta a um incidente precisa incluir a investigação do histórico, a identificação dos segredos potencialmente acessíveis e a revogação das credenciais comprometidas. Também é necessário verificar se houve alterações não autorizadas em outros projetos ou serviços vinculados à mesma conta.
Como proteger repositórios e pipelines de CI/CD contra a GhostAction
A prevenção exige controles em diferentes etapas do desenvolvimento. Se houver suspeita de comprometimento, a prioridade deve ser interromper a execução das automações suspeitas, revogar os acessos afetados e investigar a extensão do incidente.
1. Audite os arquivos de automação. Examine o diretório .github/workflows/ em todos os repositórios relevantes. Verifique arquivos adicionados recentemente, mudanças inesperadas em fluxos existentes e comandos que enviem informações para destinos externos desconhecidos. Consulte também o histórico de commits e as atividades das contas mantenedoras.
2. Revogue e substitua credenciais expostas. Faça a rotação dos PATs e de todos os segredos que possam ter sido acessados pelo fluxo malicioso. Inclua chaves da AWS, tokens de publicação de pacotes, credenciais de contêineres e chaves de API. Apenas apagar o arquivo suspeito não invalida as credenciais roubadas.
3. Ative MFA e reduza as permissões. Utilize autenticação multifator, preferencialmente com métodos resistentes a phishing, e elimine tokens desnecessários. Restrinja os escopos e os prazos de validade dos PATs. Para automações, prefira credenciais específicas e temporárias quando disponíveis.
4. Limite as permissões do GitHub Actions. Configure o GITHUB_TOKEN com os privilégios mínimos necessários para cada tarefa. Um fluxo de testes, por exemplo, normalmente não precisa de permissões para publicar pacotes ou modificar arquivos do repositório. Evite conceder permissões amplas por padrão.
5. Proteja os branches e os arquivos de workflow. Utilize regras de proteção, revisões obrigatórias e CODEOWNERS para exigir aprovação de pessoas responsáveis pelas alterações em .github/workflows/. Restrinja também as ações externas permitidas e, quando apropriado, fixe-as em hashes de commit imutáveis.
6. Automatize a detecção de segredos. Habilite recursos como secret scanning e push protection nos repositórios compatíveis. Essas ferramentas ajudam a identificar determinados tipos de credenciais antes que sejam publicados, mas não substituem a análise do histórico nem a rotação de chaves já expostas.
7. Monitore os acessos e as execuções. Revise os registros de auditoria do GitHub e os logs dos serviços conectados. Procure tokens criados inesperadamente, mudanças de permissões, publicações não autorizadas e consumo anormal de APIs. Quando possível, restrinja também as conexões de saída dos executores de CI/CD a destinos confiáveis.
GhostAction reforça a importância da segurança na cadeia de suprimentos
A campanha GhostAction mostra como o comprometimento de contas legítimas pode transformar ferramentas de automação em instrumentos de roubo de credenciais. O risco não está restrito ao GitHub: ele pode alcançar serviços de nuvem, registros de pacotes, plataformas de IA e projetos que dependem das bibliotecas afetadas.
A defesa exige uma abordagem que combine autenticação forte, menor privilégio, revisão de código, monitoramento contínuo e rotação de segredos. Também é fundamental tratar o histórico do Git como uma possível fonte de exposição, mesmo quando credenciais já foram removidas dos arquivos atuais.
Para desenvolvedores e equipes de DevOps, a recomendação é revisar os tokens ativos, conferir as permissões dos fluxos de trabalho e investigar alterações suspeitas nos repositórios. Em ambientes corporativos, essas verificações devem abranger toda a organização, não apenas os projetos nos quais foram encontrados indícios de atividade maliciosa.