Remote Code Execution in Gogs über Rebase-Feature ausnutzbar

In Gogs — einer beliebten Lösung für das Selbsthosting von Git-Repositories — wurde nach Angaben der Forscher von Rapid7 eine kritische Schwachstelle zur Remote Code Execution (RCE) mit einem CVSS-Score von 9.4 entdeckt. Die Schwachstelle ermöglicht es jedem authentifizierten Benutzer, beliebige Befehle auf dem Server auszuführen, indem ein Pull Request mit einem bösartigen Branch-Namen erstellt wird. Zum Zeitpunkt der Veröffentlichung steht kein Patch zur Verfügung, und ein öffentlich zugängliches Metasploit-Modul automatisiert bereits die vollständige Exploit-Kette. Administratoren von Gogs-Instanzen müssen umgehend Gegenmaßnahmen ergreifen — die Registrierung deaktivieren, die Erstellung von Repositories einschränken und die Einstellungen für Rebase-Merges überprüfen.

Angriffsmechanismus: Argument-Injektion in git rebase

Der Kern der Schwachstelle liegt in der unzureichenden Bereinigung von Branch-Namen bei der Ausführung der Option „Rebase before merging“. Wie der Forscher Jonah Burgess von Rapid7 berichtet, erstellt der Angreifer einen Pull Request mit einem Branch-Namen, der das Flag --exec enthält, das in den Befehl git rebase injiziert wird. Laut der offiziellen Git-Dokumentation nimmt der Parameter --exec einen beliebigen Shell-Befehl entgegen, der nach der Anwendung jedes Commits im Rahmen des Rebase-Prozesses ausgeführt wird.

Das entscheidende Merkmal der Schwachstelle ist die außerordentlich niedrige Einstiegshürde für Angreifer. Laut den Forschern sind für die Ausnutzung weder Administratorrechte noch Interaktion mit anderen Nutzern erforderlich. Auf einer Gogs-Instanz mit Standardkonfiguration stellt sich die Angriffskette wie folgt dar:

• Der Angreifer registriert ein Benutzerkonto auf der Zielinstanz
• Er erstellt ein eigenes Repository (der Ersteller wird automatisch dessen Besitzer)
• Er aktiviert die Option für Rebase-Merges — dies ist der einzige Schalter in den Einstellungen
• Er erstellt einen Pull Request mit einem bösartigen Branch-Namen, der die Injektion --exec enthält
• Bei der Ausführung des Rebase-Merge wird der beliebige Befehl auf dem Server ausgeführt

In einem alternativen Szenario, in dem die Erstellung von Repositories eingeschränkt ist, genügt es dem Angreifer, Schreibzugriff auf ein beliebiges Repository zu besitzen, in dem Rebase-Merges bereits aktiviert sind. Die Schwachstelle betrifft Berichten zufolge alle unterstützten Plattformen: Windows, Linux und macOS.

Fehlender Patch und verfügbare Exploits

Nach Angaben von Rapid7 wurde die Schwachstelle dem Maintainer des Projekts am 17. März 2026 gemeldet, doch zum Zeitpunkt der Offenlegung existiert noch keine Korrektur. Der Schwachstelle wurde kein CVE-Bezeichner zugewiesen, was ihre Nachverfolgung über Standarddatenbanken erschwert. Der CVSS-Score 9.4 stammt von Rapid7 und ist weder vom Hersteller noch von der NVD bestätigt.

Die Lage wird durch das Vorhandensein eines öffentlichen Metasploit-Moduls verschärft, das die vollständige Exploit-Kette für Linux und Windows automatisiert. Das Modul unterstützt zwei Betriebsmodi:

• Standardmodus: Es wird ein temporäres Repository unter dem Konto des Angreifers angelegt, der Exploit wird ausgeführt, anschließend wird das Repository gelöscht. Einziger verbleibender Hinweis ist ein HTTP-500-Eintrag in den Server-Logs.
• Zielmodus: Ausnutzung eines bestehenden Repositories, für das der Angreifer Schreib- und Merge-Rechte besitzt. In diesem Fall bleiben mehr Artefakte zurück.

Die minimalen Spuren in den Logs beim Einsatz des ersten Modus machen die Erkennung eines Angriffs für Incident-Response-Teams deutlich schwieriger.

Bewertung der Auswirkungen

Eine erfolgreiche Ausnutzung der Schwachstelle kann nach Einschätzung der Forscher zu folgenden Auswirkungen führen:

• Vollständige Kompromittierung des Servers mit Zugriff auf alle Repositories der Instanz
• Exfiltration von Zugangsdaten und Secrets aus den Speichern
• Laterale Bewegung zu anderen, über das Netzwerk erreichbaren Systemen
• Manipulation von Code in beliebigen gehosteten Repositories – ein potenzieller Angriffsvektor auf die Lieferkette
• Interne Datenlecks zwischen Nutzern: Auslesen privater Repositories anderer Benutzer auf demselben Server

Der letzte Punkt ist besonders kritisch für Organisationen, die eine gemeinsame Gogs-Instanz für mehrere Teams oder Projekte nutzen. Die Kompromittierung eines einzigen Kontos mit Minimalrechten kann potenziell den gesamten dort gehosteten Quellcode offenlegen.

Empfehlungen zum Schutz

Solange kein offizieller Patch verfügbar ist, sollten umgehend die folgenden Maßnahmen ergriffen werden:

• Offene Registrierung deaktivieren: In der Datei app.ini den Wert DISABLE_REGISTRATION = true setzen, um die Erstellung von Konten durch nicht vertrauenswürdige Nutzer zu verhindern
• Erstellung von Repositories einschränken: In app.ini den Wert MAX_CREATION_LIMIT = 0 setzen, damit Benutzer keine Repositories eigenständig anlegen können
• Einstellungen für Rebase-Merges prüfen: Alle Repositories daraufhin überprüfen, ob die Option „Rebase before merging“ aktiviert ist, und sie überall dort abschalten, wo sie nicht zwingend benötigt wird
• Server-Logs überprüfen: Besonderes Augenmerk auf HTTP-500-Einträge legen, die auf Exploit-Versuche hindeuten können
• Migration in Erwägung ziehen: Organisationen mit hohen Sicherheitsanforderungen sollten einen Wechsel zu aktiv gepflegten Alternativen wie Gitea (ein Fork von Gogs mit häufigeren Security-Updates) prüfen

Die Kombination aus fehlendem Patch, einem öffentlich verfügbaren Metasploit-Modul und der niedrigen Ausnutzungshürde schafft ein erhöhtes Risiko für alle Gogs-Instanzen. Vorrangige Maßnahme ist das Deaktivieren der Registrierung und von Rebase-Merges auf allen Instanzen, die aus dem Internet oder aus nicht vertrauenswürdigen Netzwerksegmenten erreichbar sind, bis ein offizieller Fix des Projekt-Maintainers vorliegt.