Uma campanha coordenada de ataque à cadeia de suprimentos de software mirou 61 repositórios públicos do GitHub em 1º de setembro de 2026. Segundo a investigação da empresa de segurança Radware, divulgada em 29 de outubro, os atacantes publicaram 83 itens maliciosos — issues, pull requests e comentários — com o objetivo de executar comandos dentro de ambientes de integração contínua (CI/CD) e tentar roubar segredos de desenvolvimento.
O que aconteceu
A atividade foi concentrada no tempo: os atacantes publicaram 77 dos 83 itens maliciosos em cerca de 43 minutos, entre 11h26 e 12h10 (UTC) de 1º de setembro. Uma segunda onda, com seis itens, ocorreu no mesmo dia. Os alvos incluíram projetos conhecidos como Google LangExtract, Trivy, Brave Browser, MLflow, ToolJet e PX4-Autopilot — o que não significa que todos esses projetos tenham sido invadidos: o impacto dependia das permissões e da configuração de cada workflow.
Como funcionava o ataque
O mecanismo era a injeção de comandos shell por meio de conteúdo não confiável processado pelo GitHub Actions. Os atacantes embutiam expressões de substituição de comando do Bash, escritas como $(), em títulos de issues e pull requests. Quando um workflow inseria esse conteúdo diretamente no código shell, o Bash interpretava a expressão como um comando a ser executado.
O payload coletava as variáveis de ambiente do processo com o comando env, codificava o resultado em Base64 e tentava enviá-lo por HTTP para um servidor controlado pelos atacantes, no endereço 54.205.16.142, porta 8443. O ataque podia ocorrer mesmo que a issue ou o pull request nunca fosse aprovado, mesclado ou se fosse fechado minutos depois de enviado.
O que foi confirmado — e o que não foi
A Radware analisou logs reais de execuções e encontrou evidência direta de que o comando malicioso entrou em execução dentro do ambiente de automação em dois casos: o pull request nº 28488 do PX4-Autopilot e uma issue do projeto workout-cool. Por outro lado, a investigação não confirmou roubo de segredos, obtenção de permissões de escrita nos repositórios, modificação de código-fonte ou comprometimento de versões distribuídas. Os segredos do GitHub Actions não ficam disponíveis automaticamente para todos os workflows, e a execução do comando, por si só, não prova que credenciais tenham sido exfiltradas.
A Radware também identificou contas do GitHub com histórico legítimo de desenvolvimento usadas para distribuir o ataque, além de um usuário que afirmou publicamente não ter criado a atividade maliciosa atribuída a ele.
O que os mantenedores devem fazer
Para projetos que usam o GitHub Actions, a recomendação dos pesquisadores é nunca interpolar conteúdo de usuários diretamente em scripts shell: passe os valores por variáveis de ambiente. Mantenedores de repositórios públicos devem revisar issues e pull requests publicados em 1º de setembro de 2026 e, por precaução, rotacionar credenciais que possam ter ficado expostas em ambientes de CI/CD.
Leia também no Geekiki: Falha no WordPress é explorada durante atualizações; CISA dá prazo até 6 de novembro.
Crédito da imagem: ilustração da Radware, publicada no blog oficial da empresa sobre a investigação.
Fontes
- Radware — Inside a GitHub Supply Chain Attack Campaign
- Cyber Security News — Hackers Target 61 GitHub Repositories With Command Injection Attacks to Steal CI/CD Secrets
- GitHub — PX4/PX4-Autopilot, Pull Request #28488
Transparência: esta matéria foi produzida com auxílio de inteligência artificial, a partir de fontes públicas da internet, e revisada com base nas fontes originais citadas abaixo. Consulte sempre as fontes originais para confirmar os detalhes.
Muse
