CVE-2026-52813-Gogs-RCE

CVE-2026-52813 (Gogs Path Traversal → Git Hooks RCE) writeup defensivo: análise de causa raiz e de patch, regras de detecção Sigma/SIEM, IOCs, scanner de versão não intrusivo. Sem PoC armado.

TL;DR

Ao criar uma organização no Gogs, o formulário Web tem a validação de caracteres AlphaDashDot que bloqueia /, mas a API REST POST /api/v1/user/orgs não tem. O atacante envia um nome de organização contendo ../ via API, contorna a validação e chega direto a os.MkdirAll(repoutil.UserPath(org.Name), 0777) (internal/database/org.go:165), gravando o diretório do repositório em caminhos arbitrários do sistema de arquivos. Combinado com a árvore de trabalho temporária do editor Web do Gogs (local-r/<repo_id>/), é possível depositar um hooks/update malicioso dentro do checkout local de outro repositório, executado automaticamente pelo git → RCE como usuário git.

Versões afetadas e remediação

A atualização é a única correção definitiva:

Mitigações temporárias (quando não for possível atualizar):

• Desative o registro aberto (app.ini → [service] DISABLE_REGISTRATION = true), reduzindo o pré-requisito de "não autenticado" para "exige conta existente";
• Na camada de proxy reverso (nginx/Caddy/Traefik), adicione regras de WAF para bloquear corpos de requisição de POST /api/v1/user/orgs e POST /api/v1/org/*/repos em que os campos username / name contenham .. ou / (veja detection/);
• Restrinja as permissões de escrita do contêiner do Gogs fora de /data/gogs/data/tmp/ (selinux/apparmor).

Análise da causa raiz

1. Assimetria de validação: a Web tem, a API não tem

Formulário Web (internal/form/org.go, v0.14.2):

API (internal/route/api/v1/org/org.go, v0.14.2):

→ O campo username de POST /api/v1/user/orgs pode carregar caracteres arbitrários direto até a camada de banco de dados.

2. A camada de banco de dados só verifica nomes reservados, não o conjunto de caracteres

internal/database/users.go:1532 isNameAllowed apenas bloqueia nomes reservados/prefixos e sufixos (como admin, -bot) e não valida o conjunto de caracteres, então ../ passa.

3. Sink de caminho sem sanitização

internal/repoutil/repoutil.go (v0.14.2):

internal/database/org.go:165:

4. Usando a árvore de trabalho local-r para plantar o hook

Ao processar edições de arquivos Web/API, o Gogs faz checkout do repositório em /data/gogs/data/tmp/local-r/<repo_id>/. O <repo_id> é exatamente o id do repositório no banco de dados. O atacante:

1. Cria um repositório pessoal writer, obtendo id == n;
2. Cria via API uma organização com path traversal username = "../../../../data/gogs/data/tmp/local-r/n/nested" → o diretório físico cai dentro da árvore de trabalho de writer;
3. Cria um repositório rce-x sob essa organização → cai em local-r/n/nested/rce-x.git;
4. Faz clone de writer, faz commit e push de nested/rce-x.git/hooks/update como arquivo comum (ele fica dentro da árvore de trabalho de writer);
5. Aciona via API uma operação de arquivo em writer → o Gogs executa git em local-r/n/ → o git executa hooks/update → RCE.

Ponto-chave: o hook malicioso entra como conteúdo comum de repositório via push normal e não exige a configuração ENABLE_GIT_HOOKS — é isso que o diferencia da rota de "abuso tradicional de git hooks".

Análise detalhada do diff do patch em patch/ANALYSIS.md.

Detecção

Regras completas em detection/:

• Regras Sigma: detection/sigma/ — cobrem tentativas de ataque (requisições de API contendo ../) e exploração bem-sucedida (materialização no sistema de arquivos)
• Consultas SIEM: detection/queries.md — Splunk / Elastic / Kibana / Loki
• IOCs: detection/iocs.md — rastros no sistema de arquivos, assinaturas de log, características de nomes de usuário

As duas mais críticas:

1. Bloqueio na camada WAF / proxy reverso: campos username/name contendo .. ou / no corpo JSON de POST /api/v1/user/orgs e POST /api/v1/org/*/repos.
2. Inspeção do sistema de arquivos: aparecimento de subdiretórios inesperados sob /data/gogs/data/tmp/local-r/*/ (nested/, rce-*.git, hooks/update).

Ferramentas defensivas

• tools/check_version.py — scanner de versão não intrusivo: verifica por meio de GET /api/v1/version se uma instância do Gogs é < 0.14.3, com suporte a varredura em lote e saída CSV, adequado para inventário de ativos.

Este repositório não fornece ferramentas de exploração weaponizadas. Para reproduzir, use o PoC público referenciado no advisory oficial e somente em ambiente isolado auto-hospedado.

Ambiente de laboratório

As regras de detection/ precisam ser validadas em um Gogs afetado; lab/docker-compose.yml fornece um ambiente isolado do Gogs 0.14.2 para o blue team testar se as regras de detecção são acionadas. Não exponha à internet pública, use apenas localmente.

Linha do tempo

Referências

• Advisory oficial: https://github.com/gogs/gogs/security/advisories/GHSA-c39w-43gm-34h5
• PR de correção: https://github.com/gogs/gogs/pull/8334
• OSV: https://osv.dev/vulnerability/CVE-2026-52813
• Release do Gogs 0.14.3: https://github.com/gogs/gogs/releases/tag/v0.14.3

⚠️ Sobre a desinformação da "injeção de parâmetro gitrebase"

Na internet, há quem descreva este CVE como "Execução remota de código por injeção de parâmetro gitrebase no Gogs" — isso está errado. Esta vulnerabilidade não tem relação com git rebase / gitrebase; a causa raiz é o path traversal na API. Este documento segue a análise da vulnerabilidade real.

Licença

MIT — veja LICENSE.