CVE-2026-52813 — Traversée de chemin dans Gogs conduisant à une exécution de code à distance via Git Hooks (Analyse défensive)

Recherche en sécurité / writeup orienté équipe bleue. Ce dépôt ne contient pas de PoC armé. Les chercheurs souhaitant reproduire doivent utiliser le PoC public référencé dans l'avis officiel.

TL;DR

Lors de la création d'une organisation dans Gogs, le formulaire Web dispose d'une validation de caractères AlphaDashDot bloquant /, mais l'API REST POST /api/v1/user/orgs ne l'a pas. L'attaquant soumet via l'API un nom d'organisation contenant ../, contourne la validation et atteint directement os.MkdirAll(repoutil.UserPath(org.Name), 0777) (internal/database/org.go:165), ce qui écrit le répertoire du dépôt dans un chemin arbitraire du système de fichiers. Combiné avec l'arbre de travail temporaire de l'éditeur Web de Gogs (local-r/<repo_id>/), il est possible de déposer un hooks/update malveillant dans le checkout local d'un autre dépôt, exécuté automatiquement par git → RCE en tant qu'utilisateur git.

Versions affectées et mesures

La mise à jour est la seule solution définitive :

# Docker
docker pull gogs/gogs:0.14.3
# Ou depuis les sources
git checkout v0.14.3 && go build

Atténuation temporaire (si mise à jour impossible) :

• Désactiver l'inscription ouverte (app.ini → [service] DISABLE_REGISTRATION = true), ce qui abaisse le prérequis de "sans authentification" à "compte existant requis" ;
• Ajouter au niveau du proxy inverse (nginx/Caddy/Traefik) des règles WAF pour bloquer les requêtes POST /api/v1/user/orgs, POST /api/v1/org/*/repos dont le corps JSON contient username / name avec .. ou / (voir detection/) ;
• Limiter les droits d'écriture du conteneur Gogs en dehors de /data/gogs/data/tmp/ (selinux/apparmor).

Analyse de la cause racine

1. Asymétrie de validation : Web oui, API non

Formulaire Web (internal/form/org.go, v0.14.2) :

type CreateOrg struct {
    OrgName string `binding:"Required;AlphaDashDot;MaxSize(35)"` // regex ^[a-zA-Z0-9._-]+$
}

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

// api.CreateOrgOption (go-gogs-client) étiquette de binding :
type CreateOrgOption struct {
    UserName string `json:"username" binding:"Required"` // ← pas de AlphaDashDot !
}

→ Le champ username de POST /api/v1/user/orgs peut contenir n'importe quel caractère et atteint directement la couche base de données.

2. La couche base de données ne vérifie que les noms réservés, pas le jeu de caractères

internal/database/users.go:1532 isNameAllowed ne bloque que les noms réservés/prefixes/suffixes (ex : admin, -bot), ne valide pas le jeu de caractères, donc ../ passe.

3. Le sink de chemin n'est pas assaini

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

func UserPath(user string) string {
    return filepath.Join(conf.Repository.Root, strings.ToLower(user)) // ← concaténation directe
}

internal/database/org.go:165 :

os.MkdirAll(repoutil.UserPath(org.Name), os.ModePerm) // org.Name contient ../ → écriture dans un chemin arbitraire

4. Utilisation de l'arbre de travail local-r pour déposer un hook

Lorsque Gogs traite les modifications de fichiers via Web/API, il extrait le dépôt dans /data/gogs/data/tmp/local-r/<repo_id>/. <repo_id> correspond exactement à l'id du dépôt dans la base de données. L'attaquant :

1. Crée un dépôt personnel writer, obtient id == n ;
2. Crée via API une organisation traversante avec username = "../../../../data/gogs/data/tmp/local-r/n/nested" → le répertoire physique tombe dans l'arbre de travail de writer ;
3. Dans cette organisation, crée un dépôt rce-x → tombe dans local-r/n/nested/rce-x.git ;
4. Clone writer, place nested/rce-x.git/hooks/update comme fichier normal, le commit et le push (il se retrouve dans l'arbre de travail de writer) ;
5. Déclenche via API une opération de fichier sur writer → Gogs exécute git dans local-r/n/ → git exécute hooks/update → RCE.

Point clé : le hook malveillant est introduit comme contenu normal du dépôt via un push normal, aucune configuration ENABLE_GIT_HOOKS n'est nécessaire — c'est la différence par rapport à la voie "abus de hooks git traditionnels".

Analyse détaillée du diff du correctif dans patch/ANALYSIS.md.

Détection

Règles complètes dans detection/ :

• Règles Sigma : detection/sigma/ — couvre les tentatives d'attaque (requêtes API contenant ../) et l'exploitation réussie (écriture sur le système de fichiers)
• Requêtes SIEM : detection/queries.md — Splunk / Elastic / Kibana / Loki
• IOCs : detection/iocs.md — traces système de fichiers, signatures de logs, caractéristiques de noms d'utilisateur

Les deux plus importantes :

1. Blocage au niveau WAF / proxy inverse : POST /api/v1/user/orgs et POST /api/v1/org/*/repos avec username/name contenant .. ou / dans le corps JSON.
2. Inspection du système de fichiers : présence de sous-répertoires inattendus (nested/, rce-*.git, hooks/update) sous /data/gogs/data/tmp/local-r/*/.

Outil défensif

• tools/check_version.py — scanneur de version non intrusif : vérifie via GET /api/v1/version si une instance Gogs est < 0.14.3, supporte le scan en masse, sortie CSV, adapté à l'inventaire des actifs.

Ce dépôt ne fournit pas d'outil d'exploitation armé. Pour reproduire, utilisez le PoC public référencé dans l'avis officiel, et uniquement dans un environnement isolé auto-hébergé.

Environnement de test

Les règles de detection/ doivent être validées sur un Gogs affecté. lab/docker-compose.yml fournit un environnement isolé Gogs 0.14.2 pour que l'équipe bleue teste si les règles de détection déclenchent. Ne pas exposer sur Internet, usage local uniquement.

Chronologie

Références

• Avis officiel : https://github.com/gogs/gogs/security/advisories/GHSA-c39w-43gm-34h5
• PR de correction : https://github.com/gogs/gogs/pull/8334
• OSV : https://osv.dev/vulnerability/CVE-2026-52813
• Release Gogs 0.14.3 : https://github.com/gogs/gogs/releases/tag/v0.14.3

⚠️ Sur la fausse rumeur "d'injection de paramètre gitrebase"

Certains décrivent en ligne cette CVE comme "Exécution de code à distance par injection de paramètre gitrebase dans Gogs" — c'est faux. Cette vulnérabilité n'a rien à voir avec git rebase / gitrebase ; la cause racine est une traversée de chemin dans l'API. Ce document suit l'analyse réelle.

License

MIT — voir LICENSE.