SchwachstellenHackerangriffeCloud-Sicherheit

Kritische Zero-Day-Lücke in Gogs ermöglicht Remote Code Execution

Kritische Zero-Day-Lücke in Gogs ermöglicht Remote Code Execution
Zusammenfassung

Die beliebte Open-Source-Software Gogs, ein selbstgehosteter Git-Service, ist Opfer einer kritischen Zero-Day-Schwachstelle geworden, die es Angreifern ermöglicht, beliebigen Code auf betroffenen Servern auszuführen. Die Sicherheitslücke mit einem CVSS-Score von 9,4 nutzt eine Argument-Injection-Flaw aus, die über Pull Requests mit bösartigen Branch-Namen exploitiert werden kann. Authentifizierte Angreifer können dabei das „--exec"-Flag in den Git-Rebase-Prozess einschleusen und damit Shell-Befehle mit den Privilegien des Gogs-Serverprozesses ausführen. Besonders problematisch ist, dass Gogs standardmäßig mit offener Registrierung und ohne Limits für die Repository-Erstellung konfiguriert ist, sodass sich Angreifer problemlos einen Account erstellen können. In Deutschland betrifft diese Schwachstelle insbesondere Unternehmen und Behörden, die Gogs als interne Versionskontrollplattform einsetzen. Die Auswirkungen sind erheblich: Angreifer könnten auf sämtliche Repositories zugreifen, Anmeldedaten stehlen, private Repositories kompromittieren und in das interne Netzwerk eindringen. Da die Gogs-Entwickler bis dato keinen Patch bereitgestellt haben, sollten betroffene Organisationen sofort ihre Systeme überprüfen und Gegenmaßnahmen implementieren.

Die Schwachstelle wurde bereits Mitte März der Gogs-Entwicklergemeinde gemeldet. Obwohl die Maintainer die Benachrichtigung bestätigten, liegt bis zum Zeitpunkt der Veröffentlichung kein Patch vor. Rapid7 hat parallel zur Veröffentlichung ein Metasploit-Modul bereitgestellt, das die komplette Exploit-Kette automatisiert.

Technischer Hintergrund: Argument Injection in Git Rebase

Die Lücke ist eine Argument-Injection-Schwachstelle, die im “Rebase before merging”-Merge-Prozess ausgenutzt wird. Während eines Standard-Merge ein Merge-Commit erstellt wird, werden bei einem Rebase die Commits des Head-Branch auf dem Base-Branch als lineare Historie überspielt. Das kritische Problem: Die Merge-Funktion übergibt den Branch-Namen des Pull-Requests an die git-rebase-Funktion, ohne nachfolgende Argumente zu validieren oder zu filtern.

Angreifer können so das Flag --exec in die rebase-Befehlszeile injizieren. Dieses Flag instruiert Git, einen Shell-Befehl nach jedem erneut eingespielten Commit auszuführen. Durch gezielt manipulierte Branch-Namen lassen sich beliebige Befehle einschleusen.

Besonders kritisch: Die “Rebase before merging”-Funktion ist zwar nicht standardmäßig aktiviert, aber jeder Repository-Owner oder Administrator kann sie mit einem Klick aktivieren. Da Gogs offene Registrierung und unbegrenzte Repository-Erstellung standardmäßig erlaubt, kann jeder unauthentifizierte Angreifer ein Konto erstellen und diese Exploit-Kette ohne Benutzerinteraktion durchführen.

Ausmaß des Schadens

Erfolgreich ausgenutzt, ermöglicht die Lücke dem Angreifer:

  • Beliebige Befehlsausführung mit den Rechten des Gogs-Server-Prozesses
  • Zugriff auf alle Repositories der Instanz, einschließlich privater Repos anderer Nutzer
  • Diebstahl von Anmeldedaten, Password-Hashes, API-Token, SSH-Schlüsseln und 2FA-Secrets
  • Lateral Movement in andere Systeme des Netzwerks
  • Manipulation von Repository-Code

Betroffene Systeme

Gogs-Server auf Windows, Linux und macOS in Standardkonfiguration sind anfällig. Besonders gefährdet sind Multi-User-Instanzen, wie sie häufig in Organisationen eingesetzt werden.

Rapid7 hat neben dem Metasploit-Modul auch Indicators of Compromise (IoCs) veröffentlicht, um Administratoren bei der Suche nach möglichen Kompromittierungen zu unterstützen.

Historischer Kontext: Zweite Zero-Day in Gogs

Dies ist bereits die zweite Zero-Day-Schwachstelle in Gogs innerhalb von sechs Monaten. Im Dezember offenbarte Wiz CVE-2025-8110, eine improper Symbolic Link Handling-Lücke, die monatelang als Zero-Day ausgenutzt wurde.

Handlungsempfehlungen für Administratoren

Gogs-Betreiber sollten sofort überprüfen, ob die “Rebase before merging”-Funktion in ihren Repositories aktiviert ist, und diese deaktivieren, bis ein Patch verfügbar ist. Zusätzlich sollten Server- und Zugriffslogs auf verdächtige Aktivitäten überwacht werden.