Gitea: Kritische Schwachstelle CVE-2026-60004 – sofortiges Update auf Version 1.27.1 erforderlich

Einleitung

Am 28. Juli 2026 veröffentlichte das Gitea-Team einen Sicherheitshinweis zu einer schwerwiegenden Schwachstelle, die die Versionen 1.17 bis 1.27.0 der selbst gehosteten Git-Plattform betrifft. Die als CVE-2026-60004 verfolgte und mit einem CVSS-Wert von 9.8 (kritisch) bewertete Sicherheitslücke ermöglicht die Ausführung beliebiger Befehle auf dem Server über die API /diffpatch. Entdeckt wurde sie vom Forscher Shai Rod (NightRang3r), der auch einen Proof-of-Concept öffentlich zugänglich machte. Die Korrektur wurde am 26. Juli implementiert und am 27. Juli mit der Version 1.27.1 freigegeben. Gitea-Cloud-Instanzen wurden automatisch aktualisiert; Administratoren von On-Premises-Instanzen müssen das Update umgehend einspielen.

Technische Analyse

Die Schwachstelle liegt in der Verarbeitung von Patches über den API-Endpunkt /diffpatch. Bei der Verarbeitung erstellt Gitea einen temporären Bare-Klon des Ziel-Repositorys. Ein Angreifer kann denselben Patch zweimal senden: Dadurch wird ein Three-Way-Merge-Konflikt erzwungen, der das Schreiben eines ausführbaren Git-Hooks – namens post-index-change – im hooks-Verzeichnis des Bare-Klons auslöst. Git führt standardmäßig alle Skripte in diesem Verzeichnis aus. Auf diese Weise kann ein Angreifer beliebigen Code einschleusen, der mit denselben Rechten wie das Gitea-Dienstkonto ausgeführt wird.

Um die Schwachstelle auszunutzen, muss der Angreifer authentifiziert sein und Schreibrechte für mindestens ein Repository besitzen. Allerdings erlaubt die Standardkonfiguration von Gitea eine offene Registrierung ohne Genehmigung: Jeder kann ein Konto und ein eigenes Repository erstellen, wodurch der Angriff faktisch auch von externen Personen ohne vorherige Zugangsdaten durchgeführt werden kann. Die Ausnutzung ist einfach und erfordert keine Interaktion mit anderen Nutzern.

Auswirkungen

Ein erfolgreicher Angriff ermöglicht eine Remote Code Execution (RCE) mit den Rechten des Gitea-Systembenutzers. Dadurch können Umgebungsvariablen ausgelesen, Datenbank-Zugangsdaten, OAuth-Tokens und SSH-Schlüssel der Repositories gestohlen sowie auf alle vom Server aus zugänglichen Dateien und Netzwerkdienste zugegriffen werden. Es droht eine vollständige laterale Kompromittierung der Infrastruktur. Die kritische Einstufung ist durch die Kombination aus entfernter Ausnutzbarkeit, geringen erforderlichen Berechtigungen und fehlender Benutzerinteraktion gerechtfertigt.

Maßnahmen

• Prioritäre Maßnahme: Aktualisieren Sie Gitea unverzüglich auf Version 1.27.1 oder höher. Der Patch verändert den Patching-Vorgang, indem der temporäre Klon von einem Bare- in einen Non-Bare-Klon umgewandelt wird, wodurch die Injektion des bösartigen Hooks verhindert wird.
• Vorübergehende Eindämmung: Die Deaktivierung der offenen Registrierung (z. B. durch Setzen von REGISTRATION_DISABLED = true oder Äquivalent) verhindert, dass neue böswillige Benutzer Konten und Repositories anlegen. Diese Maßnahme behebt nicht die Schwachstelle und bietet keinen Schutz vor bereits registrierten Nutzern mit Schreibrechten.
• Teilweise Risikominderung: Das Einhängen des für temporäre Dateien verwendeten Dateisystems mit der Option noexec kann die Ausführung von Hooks erschweren, stellt jedoch keine vollständige Lösung dar und sollte nicht als Ersatz für das Update betrachtet werden.
• Es sind keine alternativen Workarounds verfügbar.

Das Release 1.27.1 enthält außerdem eine Mitigation für ein Problem mit Dateieinbindungen im Org-mode-Renderer, dem derzeit noch keine CVE zugewiesen wurde.

FAQ

1. Welche Gitea-Versionen sind von CVE-2026-60004 betroffen?
Alle Versionen von 1.17 (einschließlich) bis 1.27.0 (einschließlich). Die am 27. Juli 2026 veröffentlichte Version 1.27.1 enthält die Korrektur.

2. Muss man authentifiziert sein, um die Schwachstelle auszunutzen?
Ja, es ist ein Konto mit Schreibrechten für ein Repository erforderlich. Da die Standardkonfiguration von Gitea jedoch eine offene Registrierung erlaubt, kann ein Angreifer ein eigenes Konto und Repository erstellen, wodurch der Exploit faktisch auch ohne vorherige Anmeldedaten aus der Ferne möglich ist.

3. Wurde die Schwachstelle bereits in realen Angriffen genutzt?
Mit Stand vom 29. Juli 2026 sind keine aktiven Ausnutzungskampagnen bekannt. Das Vorhandensein eines öffentlichen Proof-of-Concept erhöht jedoch das akute Risiko erheblich. Organisationen sollten das Update unverzüglich einspielen.