CVE-2026-60004: Gitea Diffpatch API Remote Code Execution

[!WARNING] Dieses Repository ist ausschließlich für autorisierte Sicherheitsforschung und kontrollierte Labortests vorgesehen. Führen Sie den Proof of Concept nicht gegen Systeme aus, die Ihnen nicht gehören oder für deren Prüfung Sie keine ausdrückliche Genehmigung haben.

Übersicht

CVE-2026-60004 ist eine kritische Remote-Code-Execution-Schwachstelle in Giteas diffpatch-API. Ein authentifizierter Benutzer mit der Berechtigung, ein Repository zu erstellen oder darin zu schreiben, kann einen manipulierten Patch einreichen, der dazu führt, dass ein ausführbarer Git-Hook in einem temporären Bare-Repository materialisiert wird. Wenn der Hook ausgelöst wird, werden angreiferkontrollierte Befehle mit den Rechten des Gitea-Dienstkontos ausgeführt.

Wenn die öffentliche Registrierung aktiviert ist, kann ein nicht authentifizierter Angreifer möglicherweise ein Konto erstellen und den verwundbaren authentifizierten Endpunkt erreichen.

Attribut	Details
Identifier	CVE-2026-60004
Advisory	GHSA-rcr6-4jqh-j84m
Schweregrad	Kritisch — CVSS 3.1: 9.8
Schwäche	CWE-94: Improper Control of Generation of Code
Betroffene Versionen	Gitea 1.17.0 bis 1.27.0
Behobene Version	Gitea 1.27.1
Erforderlicher Zugriff	Repository-Schreibzugriff
Ausführungskontext	Gitea-Betriebssystemkonto
CISA KEV-Datum	2026-08-25

Repository-Inhalt

Datei	Beschreibung
gitea_diffpatch_rce.py	Proof of Concept, der nur die Standardbibliothek verwendet, sich authentifiziert, ein privates Repository erstellt, den manipulierten Patch einreicht und die Befehlsausgabe abruft.
payload.patch	Beispiel-Patch, der einen ausführbaren hooks/post-index-change-Hook erstellt.
poc.png	Screenshot, der während der Laborvalidierung aufgenommen wurde.
README.md	Ursprüngliche Forschungsnotizen.

Getestete Umgebung

Der Proof of Concept wurde in der folgenden isolierten Umgebung validiert:

Komponente	Konfiguration
Gitea	1.27.0
Git	2.47.2
Deployment	Docker-Container namens gitea-lab
Dienstadresse	192.168.184.128:3000
Beobachtete Identität	uid=1000(git) gid=1000(git)

Eine erfolgreiche Ausnutzung erzeugte eine Befehlsausgabe ähnlich wie:

uid=1000(git) gid=1000(git) groups=1000(git)
Linux 6.12.20-amd64 x86_64
/data/gitea/tmp/local-repo/upload.git630501597
[exit-status=0]

Voraussetzungen

• Python 3.8 oder später
• Netzwerkzugriff auf die Ziel-Gitea-Instanz
• Ein gültiges Gitea-Konto mit Berechtigungen zum Erstellen und Schreiben von Repositories oder eine Ziel-Laborinstanz mit aktivierter öffentlicher Registrierung
• Eine ausdrücklich autorisierte Testumgebung

Das Skript verwendet nur Pythons Standardbibliothek und erfordert keine zusätzlichen Pakete.

Verwendung

python3 gitea_diffpatch_rce.py <base_url> <username> <password> "<command>"

Beispiel für eine lokale Laborinstanz:

python3 gitea_diffpatch_rce.py \
  http://127.0.0.1:3000 \
  pocuser \
  'P@ssw0rd!' \
  'id; uname -a'

Das Skript versucht zunächst die Web-Registrierung und authentifiziert sich anschließend mit den angegebenen Anmeldedaten. Dadurch funktioniert derselbe Befehl sowohl mit einem neuen Konto auf einer Instanz mit offener Registrierung als auch mit einem bestehenden Konto.

Technische Analyse

Die Exploit-Kette besteht aus vier Phasen:

1. Angreiferkontrollierte Patch-Einreichung
   POST /api/v1/repos/{owner}/{repo}/diffpatch wendet den übergebenen Patch-Inhalt mit git apply --index --recount --cached --binary --ignore-whitespace --whitespace=fix -3 innerhalb eines temporären Clones an.

2. Platzierung des Hook-Pfads
   Das temporäre Repository wird als Bare-, Shared-Clone erstellt. In einem Bare-Repository ist das Repository-Stammverzeichnis auch $GIT_DIR; folglich wird der Patch-Pfad hooks/post-index-change innerhalb von Gits aktivem Hooks-Verzeichnis aufgelöst.

3. Materialisierung des ausführbaren Hooks
   Derselbe Patch wird zweimal eingereicht. Die zweite Anwendung erzeugt einen Add/Add-Konflikt, wodurch der Three-Way-Fallback den Pfad mit Modus 100755 auf der Festplatte materialisiert, trotz der Verwendung von --cached. Ein anschließendes Index-Update ruft post-index-change auf und führt den injizierten Shell-Code als Gitea-Dienstkonto aus.

4. Git-native Ausgabeabfrage
   Der Hook identifiziert das Ursprungs-Repository über objects/info/alternates, speichert die Befehlsausgabe als Git-Blob, erstellt einen Tree und Commit und aktualisiert refs/heads/output-leak. Der Proof of Concept ruft das Ergebnis anschließend über Giteas Raw-File-API ab. Diese Technik erfordert keine direkte ausgehende Verbindung vom Ziel.

Auswirkung

Eine erfolgreiche Ausnutzung gewährt Befehlsausführung mit den Rechten des Gitea-Dienstkontos. Je nach Deployment-Konfiguration kann ein Angreifer möglicherweise auf Folgendes zugreifen:

• app.ini und Datenbank-Anmeldedaten
• SECRET_KEY, INTERNAL_TOKEN und LFS-bezogene Secrets
• Repositories, die vom Gitea-Prozess gemountet oder gelesen werden können
• Prozessumgebungsvariablen
• Interne Dienste, die vom Gitea-Host oder -Container aus erreichbar sind

Es wurde bestätigt, dass das Laborkonto Lesezugriff auf app.ini hatte.

Kompromittierungsindikatoren

Verteidiger sollten die folgenden Artefakte und Anforderungsmuster untersuchen:

• Zwei identische oder nahezu identische Anfragen an /api/v1/repos/*/*/diffpatch in schneller Folge
• Ein Branch namens output-leak
• Commits, die von poc <[email protected]> verfasst wurden
• Unerwartete ausführbare Dateien namens hooks/post-index-change in Bare-Repositories oder temporären Clone-Verzeichnissen
• Verdächtige Aktivitäten unter Pfaden wie /data/gitea/tmp/local-repo/upload.git*

Diese Indikatoren beschreiben den enthaltenen Proof of Concept und sind nicht erschöpfend; ein modifizierter Exploit kann andere Pfade, Refs, Identitäten oder Ausgabekanäle verwenden.

Behebung und Gegenmaßnahmen

1. Upgrade auf Gitea 1.27.1 oder später. Dies ist die empfohlene Behebung. Der Fix ändert den betroffenen Workflow so, dass ein nicht-Bare temporärer Clone verwendet wird.
2. Beschränken Sie die diffpatch-API am Reverse-Proxy, bis das Upgrade abgeschlossen ist, beispielsweise indem Sie den Zugriff auf passende /api/v1/.../diffpatch-Routen verweigern. Validieren Sie die Regel vor dem Deployment gegen legitime Integrationen.
3. Deaktivieren Sie die öffentliche Registrierung, indem Sie DISABLE_REGISTRATION=true setzen, falls sie nicht betrieblich erforderlich ist. Dies reduziert die nicht authentifizierte Erreichbarkeit, schützt aber nicht vor bestehenden Benutzern mit Repository-Schreibzugriff.
4. Überprüfen Sie Logs und Repository-Refs auf die oben genannten Indikatoren und rotieren Sie Anmeldedaten oder Secrets, auf die das Gitea-Konto zugreifen kann, wenn eine Kompromittierung vermutet wird.

Für den in dieser Forschung verwendeten Laborcontainer kann der Abbau mit folgendem Befehl durchgeführt werden:

docker rm -f gitea-lab

Verantwortungsvolle Nutzung