Vulnerabilidade sem identificador CVE permite que contas registradas acionem execução de código no servidor ao abusar do nome de um ramo durante operação de rebase antes da mesclagem.
| Componente | Gogs, serviço Git auto-hospedado, especificamente o fluxo de pull request com mesclagem por rebase habilitada. |
| Vetor | Usuário autenticado cria um pull request com nome de ramo malicioso que injeta o parâmetro --exec na operação de rebase antes da mesclagem. |
| Impacto | Execução remota de código no servidor Gogs sob condições específicas, com risco de acesso a repositórios hospedados e adulteração de código. |
| Prioridade | Desabilitar registro aberto, restringir criação de repositórios e revisar repositórios com mesclagem por rebase habilitada enquanto não houver correção. |
| Pontuação | A falha foi classificada com CVSS 9.4 e não tinha identificador CVE informado no material analisado. |
| Plataformas | O problema afeta plataformas suportadas pelo Gogs, incluindo Windows, Linux e macOS. |
| Artefatos | Em criação e remoção de repositório pelo próprio atacante, o vestígio destacado é erro HTTP 500 nos logs do servidor; exploração em repositório existente deixa artefatos adicionais. |
Uma vulnerabilidade crítica no Gogs permite execução remota de código por qualquer usuário autenticado quando a instância aceita o fluxo necessário para criação ou escrita em repositórios e a mesclagem por rebase está disponível. O problema está no encadeamento entre pull requests, nomes de ramos e a operação de rebase antes da mesclagem. O Gogs é usado como serviço Git auto-hospedado, portanto o impacto recai diretamente sobre servidores que concentram código-fonte, histórico de desenvolvimento, chaves de integração, configurações de projeto e, em alguns ambientes, automações de entrega associadas aos repositórios.
A falha recebeu pontuação CVSS 9.4 e ainda não possuía identificador CVE informado. O aspecto mais sensível é que privilégios administrativos não são requisito para o cenário principal. Em uma instalação com configuração padrão que permita registro de usuários e criação de repositórios, um invasor precisa apenas obter uma conta, criar um repositório próprio, habilitar a opção de mesclagem por rebase e operar a cadeia sem depender de interação de outro usuário. Em ambientes mais restritos, a exploração continua possível quando o atacante já possui permissão de escrita em um repositório no qual a mesclagem por rebase esteja habilitada.
O risco não se limita ao repositório controlado pelo atacante. Como a execução ocorre no servidor que hospeda a instância, uma exploração bem-sucedida pode abrir caminho para comprometimento do serviço Gogs, leitura de repositórios privados de outros usuários na mesma instalação, alteração de código hospedado e acesso a credenciais ou segredos armazenados ou alcançáveis pelo processo afetado. Também há risco de impacto entre diferentes usuários ou equipes em instâncias compartilhadas, porque um servidor multiusuário pode concentrar projetos privados sob o mesmo plano operacional.
A cadeia explora uma interação perigosa com o rebase do Git. A operação de rebase é usada para reaplicar uma sequência de commits de um ramo sobre outro ponto base, criando um histórico linear. Diferentemente de uma mesclagem tradicional, o rebase reescreve a sequência de commits ao recriá-los sobre o novo ponto de partida. Dentro desse mecanismo existe o parâmetro --exec, que permite executar uma instrução após cada commit reaplicado. A vulnerabilidade surge quando um nome de ramo malicioso consegue influenciar a chamada de rebase feita pelo Gogs durante a operação Rebase before merging.
No cenário de configuração padrão descrito, o usuário registrado cria um repositório do qual se torna proprietário automaticamente. A partir dessa condição, habilita a mesclagem por rebase nas configurações do repositório e cria um pull request com nome de ramo preparado para injetar o parâmetro de execução. Quando o fluxo de rebase antes da mesclagem é acionado, a construção inadequada dos argumentos permite que o comportamento do Git seja desviado para executar código no servidor. O detalhe operacional do payload não é necessário para defesa e deve ser tratado como material de exploração, mas a condição relevante para detecção é a combinação entre criação de conta, criação de repositório, alteração de configuração de mesclagem, pull request e erro ou comportamento anômalo durante rebase.
Há um segundo cenário para ambientes que não permitem criação ampla de repositórios. Se um usuário já tiver escrita em um repositório com mesclagem por rebase habilitada, a cadeia pode ser acionada diretamente nesse repositório. Isso reduz a dependência de registro aberto, mas mantém a necessidade de permissão de escrita e da configuração vulnerável. O problema foi relatado ao mantenedor em 17 de março de 2026 e permanecia sem correção no momento da publicação original. A existência de automação pública para exploração aumenta a urgência de controles compensatórios, especialmente em instâncias expostas à internet ou acessíveis por usuários não plenamente confiáveis.
A superfície principal inclui instâncias Gogs auto-hospedadas em que usuários podem se registrar, criar repositórios e ajustar opções de mesclagem. Esse conjunto de permissões transforma uma conta comum em ponto de entrada suficiente para executar a cadeia, porque o usuário passa a controlar o repositório, o ramo e a configuração de rebase. Mesmo em ambientes internos, essa condição é relevante: servidores Git costumam ser acessíveis a prestadores, equipes temporárias, contas de automação e usuários com diferentes níveis de confiança.
Instâncias com criação de repositórios bloqueada não devem ser consideradas automaticamente imunes. O requisito muda para acesso de escrita em algum repositório que já tenha mesclagem por rebase habilitada. Portanto, a análise precisa cruzar permissões de escrita, configuração de mesclagem e histórico recente de pull requests. O contexto também informa uma estimativa de 1.141 instâncias Gogs expostas à internet, com possibilidade de número real maior devido a implantações atrás de VPNs ou redes internas. O impacto foi indicado para plataformas suportadas pelo Gogs, incluindo Windows, Linux e macOS.
- Instâncias Gogs com registro de novos usuários permitido ficam expostas ao cenário de conta comum criando a própria cadeia de exploração.
- Repositórios que permitem mesclagem por rebase são o ponto funcional necessário para acionar a falha.
- Usuários com permissão de escrita em repositórios existentes podem explorar o problema quando o rebase antes da mesclagem já estiver habilitado.
- Servidores compartilhados ampliam o risco porque repositórios privados de outros usuários podem ficar acessíveis após comprometimento do serviço.
- Ambientes Windows, Linux e macOS são relevantes, pois a falha foi descrita como aplicável às plataformas suportadas.
A investigação deve começar por eventos administrativos e de aplicação no Gogs. Em instâncias com registro aberto, procure a sequência temporal de criação de conta, criação de repositório, alteração de configuração de mesclagem para permitir rebase e abertura de pull request com nome de ramo incomum. O nome do ramo é peça central do vetor, então ramos contendo padrões de opção, separadores incomuns, caracteres de escape, sintaxe inesperada ou estrutura que se pareça com argumento de linha de comando devem ser tratados como sinal de alto risco, mesmo que a tentativa não tenha resultado em execução bem-sucedida.
Os logs do servidor também são relevantes porque o cenário em que o atacante cria e remove o próprio repositório pode deixar como vestígio destacado apenas um erro HTTP 500. Esse sinal isolado é fraco, mas ganha peso quando aparece próximo a eventos de criação e exclusão de repositório por usuário recém-criado ou pouco conhecido. Para exploração em repositório existente, a análise deve incluir histórico de pull requests, ramos criados recentemente, alterações de configuração de mesclagem e eventos de rebase que falharam ou foram executados fora do padrão esperado.
No endpoint e no sistema operacional do servidor Gogs, a defesa deve procurar processos filhos inesperados iniciados a partir do serviço, execução de binários não associados ao fluxo normal de Git, acesso anômalo a diretórios de repositórios e leitura de arquivos de configuração que possam conter credenciais. A rede deve ser revisada para conexões de saída incomuns feitas pelo host do Gogs após erros de rebase ou pull requests suspeitos. Como o impacto pode alcançar outros repositórios na mesma instância, a investigação não deve se limitar ao projeto usado como gatilho.
- Contas recém-criadas seguidas por criação de repositório, mudança de configuração de mesclagem e pull request em curto intervalo.
- Ramos com nomes contendo padrões compatíveis com tentativa de passar opções ao Git, especialmente associados a rebase antes da mesclagem.
- Erros HTTP 500 próximos de criação, exploração e exclusão de repositório pelo mesmo usuário.
- Processos filhos inesperados do serviço Gogs ou do processo Git durante operações de rebase.
- Acesso fora do padrão a repositórios privados, arquivos de configuração, credenciais locais ou diretórios de projetos não relacionados ao pull request.
- Conexões de saída incomuns originadas do servidor Gogs após eventos de pull request ou rebase.
Enquanto não houver correção disponível, a prioridade é reduzir as precondições da exploração. O registro aberto deve ser desabilitado para impedir que usuários não confiáveis criem contas por conta própria. A criação de repositórios por usuários comuns também deve ser bloqueada quando não for estritamente necessária, usando controles administrativos equivalentes a DISABLE_REGISTRATION e MAX_CREATION_LIMIT no arquivo app.ini. Essas medidas não corrigem a falha, mas removem o caminho mais direto descrito para instâncias com configuração padrão.
A segunda frente é revisar repositórios que já permitem mesclagem por rebase. Onde a opção não for indispensável, ela deve ser desativada até existir correção confiável. Em repositórios que precisem manter esse fluxo, limite permissão de escrita a usuários e contas de automação com necessidade real, audite ramos e pull requests recentes e valide se houve erro HTTP 500 ou comportamento anômalo associado. Contas desconhecidas, criadas recentemente ou sem vínculo operacional claro devem ser suspensas até revisão.
A resposta também deve considerar contenção pós-exploração. Se houver suspeita de execução remota, trate o servidor Gogs como potencialmente comprometido: preserve logs, isole o host quando possível, revise processos, arquivos modificados e acessos a repositórios privados, e rotacione credenciais que possam estar armazenadas no serviço ou acessíveis pelo ambiente. Como o impacto inclui adulteração de código, pipelines e consumidores dos repositórios devem ser verificados para detectar alterações não autorizadas em commits, configurações e artefatos de build.
- Desabilitar registro público de usuários em instâncias Gogs acessíveis por pessoas não confiáveis.
- Restringir criação de repositórios por usuários comuns enquanto a falha permanecer sem correção.
- Desativar mesclagem por rebase em repositórios que não dependem desse fluxo.
- Revisar permissões de escrita em repositórios com rebase antes da mesclagem habilitado.
- Investigar erros HTTP 500 ligados a pull requests, criação e exclusão de repositórios.
- Rotacionar credenciais e revisar integridade de repositórios caso haja indício de exploração.
0 Comentários