noticias

Ataque em massa mira 61 repositórios do GitHub e expõe risco de roubo de credenciais

CATEGORIA: SEGURANÇA DIGITAL

Linha fina: Campanha coordenada utilizou comentários e solicitações de alteração para executar comandos maliciosos em sistemas automatizados de desenvolvimento.

Meta description: Ataque coordenado mira 61 repositórios do GitHub com comandos maliciosos. Entenda os riscos para desenvolvedores e a segurança dos softwares.

Slug: `ataque-github-61-repositorios-credenciais`

Criminosos inseriram comandos maliciosos em comentários e solicitações de alteração para explorar sistemas automatizados de desenvolvimento e tentar capturar credenciais.

Projetos conhecidos, incluindo ferramentas do Google, Brave e Trivy, apareceram entre os alvos.

A investigação confirmou execução de comandos em dois casos, mas não comprovou roubo de credenciais ou adulteração de softwares.

Entenda o que aconteceu e por que isso preocupa toda a cadeia de desenvolvimento na PixBugTech.

\#GitHub #Ciberseguranca #OpenSource #PixBugTech

Ataque em massa mira 61 repositórios do GitHub e expõe risco de roubo de credenciais

Uma campanha coordenada de ataques cibernéticos atingiu 61 repositórios públicos do GitHub em uma operação concentrada principalmente em apenas 43 minutos. Os invasores utilizaram funcionalidades legítimas da plataforma para tentar executar comandos maliciosos nos ambientes responsáveis por testar, compilar e distribuir softwares.

A investigação, conduzida pelos pesquisadores Zvika Babo e Gabi Nakibly, da empresa de segurança Radware, identificou 83 publicações maliciosas distribuídas entre diferentes projetos de código aberto, incluindo ferramentas utilizadas por milhares de desenvolvedores e organizações.

Os ataques ocorreram em 1º de setembro de 2026, mas os resultados da investigação foram divulgados em 29 de outubro.

O objetivo aparente era obter credenciais e tokens de acesso utilizados pelos sistemas automatizados, criando condições para uma eventual invasão de repositórios e adulteração de programas distribuídos a terceiros.

A descoberta é preocupante porque revela uma fragilidade que pode existir mesmo em projetos mantidos por equipes experientes: a possibilidade de transformar informações enviadas por usuários externos em comandos executados automaticamente.

Como os criminosos tentaram invadir os repositórios?

O método explorava recursos comuns do GitHub, como Issues, Pull Requests e comentários.

Essas funcionalidades permitem que desenvolvedores relatem problemas, proponham modificações e participem da manutenção de projetos. Em repositórios públicos, parte dessas interações pode ser realizada por pessoas que não integram a equipe responsável pelo software.

Os criminosos aproveitaram essa abertura para inserir instruções maliciosas em conteúdos aparentemente comuns.

Os comandos eram ocultados em partes do texto que não aparecem normalmente na visualização da página, como comentários HTML, ou incorporados em títulos e descrições de solicitações de alteração.

O ataque se tornava possível quando um sistema automatizado processava essas informações de maneira insegura.

O papel do GitHub Actions

O GitHub Actions é uma ferramenta que automatiza atividades relacionadas ao desenvolvimento de software, incluindo testes, verificações de código, compilação e publicação de versões.

Esses processos, conhecidos como workflows, podem começar automaticamente quando determinados eventos acontecem.

Por exemplo, um projeto pode configurar uma automação para verificar se o título de uma solicitação de alteração segue um padrão ou enviar uma notificação sempre que alguém relata um problema.

O risco aparece quando o conteúdo fornecido por um usuário externo é inserido diretamente em um comando de sistema operacional, sem tratamento adequado.

Nessa situação, o texto deixa de funcionar apenas como informação e pode ser interpretado como uma instrução executável.

Foi exatamente esse comportamento que os invasores procuraram explorar.

Ataques aconteceram em uma janela de apenas 43 minutos

A velocidade da operação foi um dos elementos que chamaram a atenção dos pesquisadores.

Dos 83 conteúdos maliciosos identificados, 77 foram publicados entre 11h26 e 12h10, no horário UTC, em 1º de setembro. Uma segunda onda, com seis ocorrências, foi registrada posteriormente no mesmo dia, concentrada em aproximadamente dois minutos.

A investigação também identificou a utilização de 74 contas diferentes do GitHub.

Algumas apresentavam históricos legítimos de desenvolvimento, levantando a possibilidade de que credenciais de usuários reais tenham sido comprometidas. Essa hipótese, entretanto, não foi comprovada para todas as contas envolvidas.

A utilização de múltiplos perfis, comandos semelhantes e infraestrutura compartilhada reforçou a avaliação de que os ataques integravam uma única campanha coordenada.

Google, Brave e ferramentas de segurança apareceram entre os alvos

A lista de repositórios inclui projetos conhecidos em diferentes segmentos da indústria de software.

Entre os alvos identificados estavam:

• Google LangExtract: ferramenta relacionada à extração estruturada de informações de textos.

• Trivy: solução de segurança utilizada para identificar vulnerabilidades e problemas de configuração.

• Brave Browser: navegador com foco em privacidade e proteção de dados.

• MLflow: plataforma utilizada para gerenciar processos de desenvolvimento e operação de modelos de aprendizado de máquina.

• Qwen Code: ferramenta de programação associada ao ecossistema de modelos Qwen.

• Cilium: projeto relacionado a redes, conectividade e segurança de ambientes em contêineres.

• Homebrew Cask: componente do ecossistema de gerenciamento de aplicativos para macOS.

• PX4 Autopilot: plataforma aberta utilizada no desenvolvimento de sistemas de controle de drones.

A presença desses projetos demonstra a diversidade dos alvos escolhidos, abrangendo inteligência artificial, navegadores, infraestrutura, segurança e automação.

É importante destacar, porém, que estar na lista de alvos não significa que o projeto tenha sido efetivamente invadido ou que seus programas tenham sido contaminados.

A pesquisa identificou tentativas de exploração, mas não confirmou comprometimento de todos os repositórios envolvidos.

Pesquisadores confirmaram execução de comandos em dois casos

A investigação não se limitou a encontrar publicações suspeitas. Os pesquisadores examinaram registros de execução do GitHub Actions para determinar se as instruções haviam sido processadas pelas automações dos projetos.

Em dois casos, encontraram evidências de que comandos maliciosos realmente foram executados.

Um dos exemplos envolveu o repositório PX4-Autopilot. Uma solicitação de alteração aparentemente simples, apresentada como correção de um erro na documentação, continha uma instrução incorporada ao título.

Quando o sistema automatizado verificou esse título, acabou interpretando parte do conteúdo como um comando executável.

A instrução tentava coletar variáveis de ambiente e transmitir os dados para um servidor externo controlado pelos invasores.

Essas variáveis podem conter informações utilizadas por serviços automatizados, incluindo configurações de compilação, identificadores e, dependendo das permissões concedidas, credenciais sensíveis.

Apesar da confirmação da execução dos comandos, a Radware ressaltou que não conseguiu comprovar o roubo efetivo de credenciais, a obtenção de permissões de escrita ou a modificação de códigos distribuídos aos usuários.

Essa distinção é fundamental: a pesquisa demonstrou uma exploração real de automações vulneráveis, mas não confirmou que os invasores conseguiram completar as etapas posteriores de comprometimento.

Por que esse ataque representa uma ameaça à cadeia de suprimentos de software?

A chamada cadeia de suprimentos de software envolve todos os componentes, ferramentas e processos utilizados para desenvolver, testar e distribuir um programa.

Um aplicativo aparentemente independente pode depender de dezenas ou centenas de bibliotecas externas. Muitas delas são mantidas publicamente no GitHub.

Se um criminoso consegue comprometer um projeto utilizado por outras aplicações, o problema pode ultrapassar os limites do repositório originalmente atacado.

O risco é especialmente elevado quando credenciais comprometidas permitem modificar códigos, publicar novas versões ou interferir nos processos de distribuição.

Nesse cenário, uma atualização aparentemente legítima pode se tornar um mecanismo de propagação de códigos maliciosos.

No caso investigado pela Radware, essa possibilidade foi identificada como um objetivo potencial dos ataques, não como um resultado comprovado.

Ainda assim, a operação evidencia como uma falha aparentemente pequena no tratamento de informações externas pode abrir caminho para consequências muito mais graves.

O que os desenvolvedores devem fazer para evitar ataques semelhantes?

O problema não está simplesmente na utilização do GitHub Actions, mas na maneira como determinadas automações lidam com conteúdos que podem ser manipulados por pessoas externas.

A própria documentação de segurança do GitHub alerta para riscos de injeção de comandos quando informações como títulos, comentários e descrições são utilizadas diretamente em scripts.

Algumas medidas são especialmente importantes:

1\. Tratar informações externas como dados não confiáveis. Títulos, comentários e descrições de solicitações de alteração não devem ser incorporados diretamente a comandos executáveis.

2\. Revisar os workflows do GitHub Actions. Arquivos de automação precisam ser examinados para identificar situações em que conteúdos externos possam provocar execução indevida de código.

3\. Aplicar o princípio do menor privilégio. Tokens e contas utilizados nas automações devem receber apenas as permissões necessárias para cada tarefa.

4\. Restringir o acesso a credenciais sensíveis. Senhas, chaves de API e tokens não devem ficar disponíveis indiscriminadamente para processos iniciados por usuários externos.

5\. Separar operações públicas de tarefas privilegiadas. Automações acionadas por comentários e solicitações externas não devem compartilhar desnecessariamente o mesmo nível de acesso utilizado para publicar versões ou modificar repositórios.

6\. Monitorar os registros de execução. Atividades inesperadas, comandos desconhecidos e conexões com servidores externos devem ser investigados.

Também é recomendável utilizar variáveis de ambiente intermediárias para receber conteúdos externos em scripts, evitando que esses valores sejam inseridos diretamente na construção de comandos.

Essas práticas reduzem a superfície de ataque e dificultam a exploração de automações mesmo quando criminosos conseguem publicar conteúdos maliciosos.

O GitHub foi invadido?

Não há evidências, nessa investigação, de que a infraestrutura central do GitHub tenha sido comprometida.

Os ataques exploraram configurações inseguras de automação em repositórios hospedados na plataforma, aproveitando funcionalidades legítimas de colaboração entre desenvolvedores.

Essa diferença importa porque não se trata de uma falha generalizada que permita executar comandos em qualquer projeto.

Para que a exploração funcione, é necessário que determinada automação processe conteúdo controlado pelo invasor de maneira vulnerável.

Portanto, repositórios corretamente configurados não ficam automaticamente expostos apenas por receberem comentários ou solicitações de alteração suspeitas.

O verdadeiro problema está na confiança concedida às automações

A campanha identificada pela Radware chama atenção para uma mudança importante no cenário de segurança do desenvolvimento de software.

Ferramentas de integração e entrega contínua passaram a executar tarefas que anteriormente dependiam de intervenção humana. Esse avanço trouxe produtividade, mas também ampliou as consequências de configurações inadequadas.

Quando uma automação possui acesso a credenciais, servidores e mecanismos de publicação, ela se transforma em um componente sensível da infraestrutura tecnológica.

A investigação demonstra que um invasor não precisa necessariamente encontrar uma vulnerabilidade complexa no código de uma aplicação. Em determinadas circunstâncias, basta explorar a maneira como uma ferramenta automatizada interpreta informações externas.

O alerta deixado pelos 61 repositórios é claro: automatizar processos não elimina a necessidade de estabelecer limites de confiança.

À medida que projetos de código aberto passam a integrar aplicações corporativas, serviços digitais e ferramentas de inteligência artificial, proteger os mecanismos responsáveis por desenvolver e distribuir esses componentes torna-se tão importante quanto proteger o software final.