CVE-2026-52813-Gogs-RCE

CVE-2026-52813 (Gogs Path Traversal → Git Hooks RCE) analisi difensiva: analisi della causa principale e della patch, regole di rilevamento Sigma/SIEM, IOC, scanner di versioni non intrusivo. Nessun PoC armato.

TL;DR

Quando Gogs crea un'organizzazione, il form Web applica la validazione dei caratteri AlphaDashDot che blocca /, ma la REST API POST /api/v1/user/orgs non lo fa. Un attaccante può inviare tramite API un nome di organizzazione contenente ../, aggirando la validazione e arrivando direttamente a os.MkdirAll(repoutil.UserPath(org.Name), 0777) (internal/database/org.go:165), scrivendo la directory del repository in un percorso arbitrario del file system. Combinando ciò con l'albero di lavoro temporaneo dell'editor Web di Gogs (local-r/<repo_id>/), è possibile collocare un hooks/update malevolo all'interno del checkout locale di un altro repository, che viene eseguito automaticamente da git → RCE con l'utente git.

Versioni interessate e rimedio

L'aggiornamento è l'unica soluzione definitiva:

Mitigazioni temporanee (se non è possibile aggiornare):

• Disattivare la registrazione aperta (app.ini → [service] DISABLE_REGISTRATION = true), riducendo il prerequisito da "non autenticato" ad "account già esistente";
• Aggiungere a livello di reverse proxy (nginx/Caddy/Traefik) regole WAF che blocchino le richieste POST /api/v1/user/orgs e POST /api/v1/org/*/repos il cui corpo contenga .. o / nei campi username / name (vedi detection/);
• Limitare i permessi di scrittura del container Gogs a percorsi diversi da /data/gogs/data/tmp/ (selinux/apparmor).

Analisi della causa principale

1. Validazione asimmetrica: il Web la ha, l'API no

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

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

→ Il campo username di POST /api/v1/user/orgs può contenere caratteri arbitrari e arrivare direttamente al livello DB.

2. Il livello DB controlla solo i nomi riservati, non il set di caratteri

internal/database/users.go:1532 isNameAllowed blocca solo nomi riservati/prefissi/suffissi (es. admin, -bot), non valida il set di caratteri, quindi ../ passa.

3. Il sink del percorso non viene sanificato

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

internal/database/org.go:165:

4. Utilizzo dell'albero di lavoro local-r per depositare la hook

Quando Gogs gestisce le modifiche ai file tramite Web/API, effettua il checkout del repository in /data/gogs/data/tmp/local-r/<repo_id>/. <repo_id> coincide esattamente con l'id del repository nel database. L'attaccante:

1. Crea un repository personale writer, ottenendo id == n;
2. Tramite API crea un'organizzazione "traversale" con username = "../../../../data/gogs/data/tmp/local-r/n/nested" → la directory fisica finisce nell'albero di lavoro di writer;
3. Crea un repository rce-x sotto quell'organizzazione → finisce in local-r/n/nested/rce-x.git;
4. Clona writer, committa e pusha nested/rce-x.git/hooks/update come file normale (finisce nell'albero di lavoro di writer);
5. Tramite API attiva un'operazione sui file di writer → Gogs esegue git in local-r/n/ → git esegue hooks/update → RCE.

Punto chiave: la hook malevola entra tramite una normale push come contenuto ordinario del repository, senza bisogno della configurazione ENABLE_GIT_HOOKS — questa è la differenza rispetto alla strada dell'"abuso tradizionale delle git hooks".

L'analisi dettagliata del diff della patch è in patch/ANALYSIS.md.

Rilevamento

Le regole complete sono in detection/:

• Regole Sigma: detection/sigma/ — coprono i tentativi di attacco (richieste API con ../) e lo sfruttamento riuscito (scrittura sul file system)
• Query SIEM: detection/queries.md — Splunk / Elastic / Kibana / Loki
• IOC: detection/iocs.md — tracce sul file system, firme nei log, caratteristiche dei nomi utente

Le due più importanti:

1. Blocco a livello WAF / reverse proxy: richieste POST /api/v1/user/orgs e POST /api/v1/org/*/repos il cui corpo JSON contenga .. o / nei campi username/name.
2. Ispezione del file system: presenza di sottodirectory inattese sotto /data/gogs/data/tmp/local-r/*/ (nested/, rce-*.git, hooks/update).

Strumenti difensivi

• tools/check_version.py — scanner di versioni non invasivo: verifica tramite GET /api/v1/version se un'istanza Gogs è < 0.14.3, supporta scansioni in batch e output CSV, adatto per l'inventario degli asset.

Questo repository non fornisce strumenti di sfruttamento weaponizzati. Per la riproduzione, utilizzare il PoC pubblico citato nell'advisory ufficiale ed eseguirlo solo in un ambiente isolato allestito da voi.

Ambiente di laboratorio

Le regole in detection/ devono essere verificate su un Gogs vulnerabile; lab/docker-compose.yml fornisce un ambiente Gogs 0.14.2 isolato affinché la blue team possa testare se le regole di rilevamento scattano. Non esporlo a Internet, usarlo solo in locale.

Cronologia

Riferimenti

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

⚠️ Sulla falsa notizia dell'"iniezione di parametri gitrebase"

In rete c'è chi descrive questa CVE come "Gogs gitrebase parameter injection leading to remote code execution" — è sbagliato. Questa vulnerabilità non ha nulla a che fare con git rebase / gitrebase; la causa principale è il path traversal dell'API. Questo documento analizza la vulnerabilità reale.

Licenza

MIT — vedi LICENSE.