Forgejo schließt kritische Codeausführungslücke in Vorlagen-Repositories

Wer Forgejo als eigene Git-Plattform betreibt, hat seit dem 10. September 2026 ein Update einzuspielen. Das Projekt hat die Versionen 16.0.4 und 15.0.8 veröffentlicht, die zwei Sicherheitslücken beheben. Eine davon erlaubt die Ausführung beliebiger Prozesse auf dem Server, auf dem Forgejo läuft.

Die Besonderheit dieser Lücke: Sie braucht keinen Administratorzugang und keinen Zugriff auf das Dateisystem. Es genügt, dass jemand mit einem Benutzerkonto ein neues Repository aus einer präparierten Vorlage erzeugt. Für Instanzen, auf denen sich Nutzer selbst registrieren können oder auf denen viele Projektbeteiligte arbeiten, ist das ein direkter Weg vom normalen Nutzerkonto zum Servermissbrauch.

Was ist passiert?

Die Lücke steckt im Ablauf, mit dem Forgejo ein neues Repository aus einem Vorlagen-Repository erzeugt. Das Projekt beschreibt den Vorgang in den Versionshinweisen so: Forgejo klont das Vorlagen-Repository, entfernt den Ordner .git, führt die Variablenexpansion für die in .forgejo/template gelisteten Dateien durch und legt anschließend ein neues Git-Repository an.

Genau in diesem Ablauf liegt der Fehler. Die Variablenexpansion konnte missbraucht werden, um einen neuen Ordner .git zu erzeugen. Git übernimmt diesen Ordner bei der anschließenden Initialisierung des neuen Repositories. Ein bösartiges Vorlagen-Repository kann darüber beliebige Daten vom Forgejo-Host lesen und beliebige Prozesse auf dem Host starten, also Code ausführen.

Der Fix ist entsprechend direkt: Nach Abschluss der Variablenexpansion entfernt Forgejo einen eventuell vorhandenen Ordner .git aus dem Verzeichnis, bevor das Git-Repository initialisiert wird.

Die Schwachstelle wird als CVE-2026-89094 geführt. Der Sicherheitsdienst securityonline.info nennt einen CVSS-Wert von 9.9 nach CVSS Version 3 und gibt an, dass bisher keine Ausnutzung bestätigt ist. Diese Bewertung stammt nicht vom Forgejo-Projekt selbst, sondern von einer Sekundärquelle, und sollte entsprechend eingeordnet werden.

Wer ist betroffen?

• Alle selbst gehosteten Forgejo-Instanzen vor Version 16.0.4 beziehungsweise vor 15.0.8.
• Besonders exponiert sind Instanzen mit offener Registrierung oder mit vielen externen Mitarbeitenden, weil dort der Kreis derer groß ist, die ein eigenes Vorlagen-Repository anlegen können.
• Instanzen mit geschlossenem, kleinem Nutzerkreis sind nicht automatisch sicher, aber das Risiko sinkt deutlich, weil ein Angreifer erst ein Konto braucht.

Nicht betroffen sind Umgebungen ohne Forgejo. Wer Gitea, GitLab oder GitHub nutzt, ist von dieser konkreten Meldung nicht berührt. Gitea teilt zwar historisch eine gemeinsame Codebasis mit Forgejo, die beiden Projekte haben sich aber inzwischen deutlich auseinanderentwickelt. Ob Gitea denselben Fehler aufweist, geht aus den vorliegenden Quellen nicht hervor und sollte nicht unterstellt werden.

Wie kritisch ist das?

Eine Git-Plattform ist in der Regel eines der wertvollsten Systeme im Unternehmen. Dort liegen der Quellcode, oft Zugangsdaten in Konfigurationsdateien, Bereitstellungsschlüssel und je nach Aufbau auch die Pipeline-Runner. Wer auf dem Forgejo-Host Prozesse starten kann, kann Quellcode abziehen, Zugangsdaten aus Konfigurationsdateien lesen und im schlimmsten Fall Änderungen in Projekte einschleusen, die später automatisch ausgerollt werden.

Gegen die Dringlichkeit spricht, dass ein Angreifer ein Konto auf der Instanz braucht und dass bislang keine aktive Ausnutzung bestätigt ist. Es liegt also kein Fall wie bei einer ungeschützt aus dem Internet erreichbaren Lücke vor, bei der ein Scan genügt.

Die praktische Empfehlung liegt damit zwischen sofortiger Notfallmaßnahme und normalem Patchzyklus: Instanzen mit offener Registrierung oder Internetzugang gehören zeitnah aktualisiert, idealerweise innerhalb weniger Tage. Rein interne Instanzen mit kleinem, vertrautem Nutzerkreis können den Patch im nächsten regulären Wartungsfenster einspielen, sollten das aber nicht auf Wochen verschieben.

Was sollten Admins jetzt tun?

• Zuerst die laufende Version feststellen. Sie steht in der Weboberfläche unter Verwaltung oder lässt sich per Kommandozeile mit forgejo --version abfragen. Bei Containerbetrieb zusätzlich das tatsächlich laufende Image-Tag prüfen, nicht nur das in der Compose-Datei eingetragene.
• Auf 16.0.4 aktualisieren, wenn die Instanz auf dem 16er-Zweig läuft. Dieser Zweig wird laut Forgejo-Projekt bis zum 29. Oktober 2026 gepflegt.
• Auf 15.0.8 aktualisieren, wenn die Instanz auf dem langfristig gepflegten 15er-Zweig läuft. Dieser Zweig wird bis zum 15. Juli 2027 unterstützt und ist damit für Unternehmen die ruhigere Wahl.
• Vor dem Update ein Backup der Datenbank und des Repository-Verzeichnisses anlegen. Ein Patch-Release erfordert laut Projektdokumentation keine manuellen Eingriffe, das entbindet aber nicht vom Backup.
• Prüfen, ob die Selbstregistrierung aktiv sein muss. In den meisten Unternehmensinstanzen ist sie es nicht und sollte abgeschaltet werden.
• Nach dem Update prüfen, ob auf dem Host ungewöhnliche Prozesse, neue Benutzerkonten oder unbekannte Cron-Einträge existieren. Das ist auch ohne konkreten Verdacht eine sinnvolle Routine bei einer Lücke dieser Klasse.
• Für die Zukunft: Das Repository security-announcements des Projekts beobachten oder dessen RSS-Feed abonnieren, damit Sicherheitsreleases nicht erst über Umwege ankommen.

Einordnung für Unternehmen

Forgejo ist bei kleinen und mittleren Unternehmen beliebt, weil es ressourcenschonend läuft, unter freier Lizenz steht und keine Nutzerlizenzen kostet. Genau daraus folgt aber auch ein typisches Betriebsproblem: Solche Systeme werden oft einmal eingerichtet und dann selten angefasst, weil sie einfach funktionieren. Ein Sicherheitsrelease wie dieses fällt dann leicht durch.

Praktisch hilft eine schlichte Regel: Jede selbst gehostete Anwendung braucht einen benannten Verantwortlichen und eine Bezugsquelle für Sicherheitsmeldungen. Bei Forgejo ist das der offizielle Releases-Bereich des Projekts. Wer zusätzlich automatisierte Benachrichtigungen über neue Container-Images einsetzt, bekommt solche Updates ohne manuelles Nachsehen mit.

Der zweite Punkt betrifft die Architektur. Eine Git-Plattform sollte nicht auf demselben Host laufen wie andere kritische Dienste, und ihre Ausführungsumgebung sollte möglichst wenig Rechte auf dem Wirtssystem haben. Genau dieser Vorfall zeigt, warum: Aus einer Anwendungsschwachstelle wird sonst unmittelbar ein Serverproblem.

Passende Anleitungen auf S-EDV

• Forgejo nativ unter Ubuntu mit systemd, nginx und MariaDB beschreibt die Einrichtung, auf die dieses Update aufsetzt.
• Container-Updates mit Diun und WUD überwachen zeigt, wie neue Image-Versionen automatisch gemeldet werden.
• Gitea als selbst gehosteter Git-Server mit Docker ist der Vergleichsartikel für die verwandte Plattform.

Quellen

• Forgejo: Releases, Versionen 16.0.4 und 15.0.8 vom 10. September 2026
• LWN.net: Forgejo 16.0.4 and 15.0.8 address critical security vulnerability, 10. September 2026
• securityonline.info: CVE-2026-89094 Forgejo Remote Code Execution Hits CVSS 9.9, 11. September 2026