Kritische RCE-Lücke in Gogs: Registrierung reicht für Server-Übernahme

Kritische RCE-Lücke in Gogs: Wenn der Branch-Name zur Waffe wird

Die Open-Source-Community steht vor einem ernsthaften Sicherheitsproblem: In Gogs, einem der beliebtesten selbsthostbaren Git-Services, wurde eine kritische Remote Code Execution (RCE)-Schwachstelle aufgedeckt. Mit einem CVSS-Score von 9.4 gehört der Fehler zu den schwerwiegendsten Kategorien. Das besonders Tückische: Jeder angemeldete Nutzer kann den Fehler ausnutzen – Administratorrechte sind nicht nötig. Und der Patch? Läßt auf sich warten.

Die Technik hinter dem Angriff

Der Sicherheitsforscher Jonah Burgess von Rapid7 hat die Lücke detailliert beschrieben. Der Angriff nutzt eine Eigenschaft von git rebase aus. Beim Rebase werden Commits einer Feature-Branch auf eine Basis-Branch neu abgespielt, um eine lineare Projektgeschichte zu erzeugen. Was viele nicht wissen: Der Befehl git rebase akzeptiert das Flag --exec, das nach jedem Replay eines Commits einen Shell-Befehl auf dem System ausführt.

Genau hier setzt die Schwachstelle an. Gogs validiert die Namen von Branches nicht ausreichend, bevor diese in den Rebase-Prozess eingespeist werden. Ein Angreifer muss lediglich einen Pull Request mit einer manipulierten Branch-Namensgebung erstellen – beispielsweise einem Namen, der das --exec-Flag und einen schädlichen Shell-Befehl injiziert. Wählt der Nutzer dann die Option „Rebase before merging“, führt der Gogs-Server den eingeschleusten Befehl mit den Rechten des Dienstes aus.

Eine fatale Kombination: Design und Standardkonfiguration

Was diesen Bug so gefährlich macht, ist die Kombination aus der technischen Schwachstelle und der Standardkonfiguration von Gogs. Bei einer frischen Installation können sich Nutzer in der Regel frei registrieren. Jeder registrierte Nutzer, der ein Repository anlegt, wird automatisch zum Besitzer dieses Repos. Somit hat der Angreifer bereits die nötigen Rechte, um die Einstellungen des Repos zu ändern – darunter auch die Aktivierung von Rebase-Merging.

Der gesamte Exploit-Chain lässt sich ohne jegliche Interaktion anderer Nutzer oder Administratoren durchführen. Hat ein Angreifer erst einmal Schreibzugriff auf ein Repository, in dem Rebase bereits aktiviert ist, reicht sogar schon das Erstellen des bösartigen Pull Requests.

Auf Gogs-Instanzen, bei denen die Erstellung neuer Repositories eingeschränkt ist, benötigt der Angreifer immerhin Schreibzugriff auf ein bestehendes Repo mit aktivierter Rebase-Option. Die Hürde ist also niedrig, insbesondere in Unternehmensumgebungen, in denen Entwickler ohnehin weitreichende Rechte besitzen.

Kritische Auswirkungen und Cross-Tenant-Gefahr

Die Folgen einer erfolgreichen Ausnutzung sind verheerend. Da Gogs in der Regel als zentraler Dienst läuft, gewährt die RCE dem Angreifer vollen Zugriff auf den Server. Er kann sämtliche auf der Instanz gehosteten Repositories – auch die privater Nutzer – auslesen und manipulieren (Cross-Tenant Data Breach). Zudem können Zugangsdaten abgegriffen und das System als Sprungbrett für weitere Angriffe im internen Netzwerk genutzt werden. Betroffen sind laut Rapid7 alle unterstützten Plattformen: Linux, Windows und macOS.

Rapid7 schätzt die Zahl der direkt internet-facing Gogs-Instanzen auf rund 1.141. Die tatsächliche Dunkelziffer ist jedoch weitaus höher, da die meisten Deployments hinter VPNs oder in internen Netzwerken laufen – was im Falle einer internen Kompromittierung durch einen bösartigen Mitarbeiter oder einen Phishing-Angriff wenig Trost spendet.

Fehlender Patch und das Metasploit-Problem

Trotz der Kritikalität der Lücke gibt es bislang keinen Patch. Der Fehler wurde dem Maintainer von Gogs bereits am 17. März 2026 gemeldet. Dass Wochen vergehen, ohne dass ein Fix veröffentlicht wird, unterstreicht ein strukturelles Problem vieler Open-Source-Projekte: Fehlende Ressourcen und Maintainer-Überlastung bei essenzieller Infrastruktur-Software.

Rapid7 hat zudem ein Metasploit-Modul veröffentlicht, das den gesamten Exploit-Chain automatisiert. Das Modul unterstützt zwei Modi: Im Standard-Modus erstellt es temporär ein Repository unter dem Account des Angreifers, führt den Exploit aus und löscht das Repo danach. Im Server-Log bleibt lediglich ein kryptischer HTTP-500-Fehler zurück – für Blue Teams ein Albtraum bei der Forensik. Der zweite Modus nutzt ein bestehendes Repository und hinterlässt deutlich mehr Spuren.

Was Admins jetzt tun müssen

Da der Patch auf sich warten lässt, sind Administratoren von Gogs-Instanzen zum Handeln gezwungen. Rapid7 empfiehlt folgende sofortige Maßnahmen in der app.ini-Konfigurationsdatei:

1. Registrierung deaktivieren: DISABLE_REGISTRATION = true verhindert, dass unbekannte Akteure Konten erstellen.
2. Repository-Erstellung einschränken: MAX_CREATION_LIMIT = 0 hindert normale Nutzer daran, eigene Repos anzulegen, was den einfachsten Angriffsvektor blockiert.
3. Rebase-Einstellungen auditieren: Überprüfen Sie, in welchen Repositories „Rebase before merging“ aktiviert ist, und deaktivieren Sie dies wo möglich.

Journalistische Einordnung

Der Vorfall ist ein Weckruf für alle, die selbsthostete Git-Services im Einsatz haben. Gogs ist ein fantastisches Tool für den Homelab- und SMB-Bereich, aber das Projekt kämpft seit Jahren mit einer zu geringen Maintainer-Dichte. Genau diese Trägheit in der Patch-Bereitstellung war auch der Grund, warum die Community-Abspaltung Gitea (und später Forgejo) ins Leben gerufen wurde. Wer heute Gogs in produktiven Unternehmensumgebungen betreibt, trägt ein massives Risiko. Die Lücke zeigt einmal mehr: Open Source ist kein Selbstläufer. Ohne aktive Community, die Sicherheitsupdates zeitnah bereitstellt, wird aus einer bequemen Self-Hosted-Lösung schnell ein Einfallstor für Angreifer – und manchmal reicht schon ein manipulierter Branch-Name.

Quelle: The Hacker News