Gitea warnt vor einer kritischen Sicherheitslücke, die es Angreifern ohne Anmeldung ermöglicht, Dateien zu lesen. Das Problem betrifft Versionen 1.22.1 bis 1.27.0 und basiert auf einer Schwäche im Org-Mode-Renderer von Gitea. Mit einem öffentlichen Repository und speziell vorbereitetem Org-Mode-Markup kann ein Angreifer Inhalte abrufen, auf die der Gitea-Dienstzugriff im Dateisystem zugreifen darf.
Die Lücke ist unter CVE-2026-59774 erfasst, erhielt die Bewertung Critical und einen CVSS-Score von 9.8. Die formale Mitteilung wurde am 2. August veröffentlicht. Gitea schließt die Lücke mit dem Release 1.27.1.
Was die Gitea Org-Mode Schwachstelle konkret ermöglicht
Der Kern der Schwachstelle ist ein File-Read-Zugriff: Ein unauthetisierter Angreifer kann jede Datei auslesen, die der Gitea-Dienst in der betroffenen Umgebung lesen kann. Wichtig: Dafür ist kein Login nötig und es wird kein Schreibzugriff auf Repositories benötigt.
Als Voraussetzung gilt, dass der Angriff über einen öffentlichen Weg läuft: Laut Gitea genügt ein öffentliches Repository sowie korrektes Org-Mode-Markup. Wenn eine Installation keine öffentlichen Repositories bereitstellt, gibt es keinen anonymen Angriffspfad über diesen Rendering-Endpunkt.
So läuft der Angriff: POST /{owner}/{repo}/markup
Der betreffende Pfad führt über das Markup-Rendering von Gitea. Konkret geht es um die Route POST /{owner}/{repo}/markup. Diese Anfrage kann optional eingeloggte Nutzung zulassen, prüft den Zugriff auf das Repository und entscheidet anhand der Leserrechte.
Entscheidend ist: Bei einer anonymen Anfrage wird die Nutzerprüfung für öffentliche Repositories aufgehoben. Damit kann ein externer Angreifer die Renderingfunktion anstoßen, sofern die Installation mindestens ein öffentliches Repository enthält und die relevanten Code-Units im Org-Mode aktiviert sind.
Warum Org-Mode hier zum Dateilesen führt
Die Schwäche liegt im Org-Mode-Renderer. In Version 1.27.0 initialisierte Gitea go-org mit org.New(), ersetzte jedoch nicht den Standard-Callback für das Lesen von Dateien. In der verwendeten go-org-Version, so wird es beschrieben, entspricht dieser Callback dem Verhalten, das auf Dateipfade direkt auf dem Server arbeitet.
Im Org-Mode kann die Direktive #+INCLUDE genutzt werden, um Inhalte einzubinden. Wenn der Renderer dabei absolute Pfade akzeptiert, kann ein Angreifer Org-Mode-Markup so vorbereiten, dass als Zielpfad Dateien auf dem Server übergeben werden. Ergebnis: Der Angreifer erhält Dateien, die der Gitea-Dienstaccount lesen darf.
Fix in Gitea 1.27.1: ReadFile überschreiben
Gitea hat den Renderer so angepasst, dass die Einbindung über Org-Mode nicht mehr auf dem Serverdateisystem aufgelöst wird. Stattdessen wird der angegebene Include-Pfad als normal gerendertes Ergebnis zurückgegeben—also als Inhalt, der nicht aus dem Dateisystem gelesen wird.
Die Änderung wurde unter anderem über einen Pull Request umgesetzt (PR #38642) und zurückportiert (PR #38645). Zusätzlich ergänzte Gitea einen Regressionstest, um das fehlerfreie Rendern von Include-Pfaden abzusichern.
Einordnung: Nicht „ein Request = RCE“, aber Kettenangriff möglich
Die Schwachstelle ist nach Gitea-Angaben nicht direkt ein einzelner Request, der sofort Remote Code Execution auslöst. Allerdings beschreibt Gitea, dass das Dateilesen unter bestimmten Umständen in weitergehende Schritte münden kann.
Dem beschriebenen Angriffspfad zufolge könnte ein Angreifer, nachdem er Dateien gelesen hat, insbesondere app.ini auswerten, daraus einen INTERNAL_TOKEN extrahieren und anschließend über den internen Logging-Mechanismus einen Git Hook injizieren. Danach könnte ein anonymer Clone diesen Hook auslösen und damit eine Form von Command-Ausführung ermöglichen.
Gitea nennt diese Kette in seiner Mitteilung. Der Bericht, auf dem diese Zusammenfassung basiert, enthält außerdem den Hinweis, dass dort kein unabhängig veröffentlichtes Exploit-Beispiel gefunden wurde, das die Kette konkret vorführt.
Was Administratoren jetzt prüfen sollten
Ein Upgrade ist nötig—aber nicht immer ausreichend, wenn es bereits zu einer Ausnutzung kam. Die Empfehlung lautet daher, zusätzlich nach möglichen Spuren zu suchen.
- Logs zu anonymen POST-Anfragen auf /{owner}/{repo}/markup prüfen.
- Achten Sie besonders auf Anfragen, die Org-Mode-Rendering anstoßen oder absolute Dateipfade übergeben.
- Wenn eine der beschriebenen Eskalationspfade versucht wurde: prüfen Sie Hook-Verzeichnisse im Repository auf unerwartete ausführbare Dateien.
Gitea nennt außerdem eine zentrale Folge, die über das reine Patchen hinausgeht: Falls das Rendering-Ende auf einer betroffenen Version erreicht wurde, sollten Administratoren damit rechnen, dass Geheimnisse im Einflussbereich des Dienstaccounts gelesen werden konnten. Dann wird empfohlen, nicht nur Tokens zu rotieren, sondern auch die damit verbundenen Authentifizierungs- und Schlüsselmaterialien.
Welche Geheimnisse zu rotieren sind (falls Exposition vermutet wird)
Wenn Sie den Verdacht haben, dass die Schwachstelle ausgenutzt wurde, sollten Sie laut Empfehlung folgende Informationen rotieren bzw. ersetzen, bevor Sie die Instanz als „wieder sauber“ betrachten:
- INTERNAL_TOKEN
- OAuth-Material
- JWT-Signing-Material
- Datenbankcredentials
Damit reduzieren Sie das Risiko, dass gestohlene Werte weiterhin für weitere Schritte missbraucht werden können.
Upgrade-Empfehlung: schnell auf 1.27.1
Gitea rät dazu, den Fix sofort umzusetzen. Für Cloud-Installationen wurde angekündigt, dass Upgrades automatisch während eines Wartungsfensters durchgeführt werden. Für selbst gehostete Umgebungen gilt: Version 1.27.1** direkt einspielen.
Die Schwachstelle ist zudem in der CVE-Welt sauber dokumentiert. Neben CVE-2026-59774 schließt Gitea 1.27.1 außerdem eine separate Schwachstelle (Remote Code Execution) unter CVE-2026-60004, die bereits in einem früheren Bericht behandelt wurde.
Transparenz zur Ausnutzung: keine bestätigte „Wild“-Exploitation
In der zusammengefassten Meldung heißt es, dass Gitea keine Ausnutzung „in freier Wildbahn“ direkt berichtet. Außerdem wird erwähnt, dass CVE-2026-59774 bis 5. August 2026 nicht im Katalog der CISA Known Exploited Vulnerabilities gelistet war. Gleichzeitig wird festgehalten, dass das Dateilesen bereits vor der formalen Advisory öffentlich vorab gezeigt wurde.
Die genaue technische Verwertung bleibt damit vor allem eine Frage des Risikos für Systeme, die weiterhin auf betroffenen Versionen laufen und öffentliche Repositories bereitstellen.
Beobachtungen zu weiterer Gitea-Sicherheitsarbeit
Der Bericht ordnet die Schwachstelle auch in einen größeren Sicherheitskontext ein: In den Monaten zuvor veröffentlichte Gitea weitere Fixes. Dazu gehört unter anderem eine kritische Umgehung rund um Reverse-Proxy-Authentifizierung in bestimmten Docker-Images (CVE-2026-20896) sowie eine Sicherheitslücke im Container-Registry-Zugriffskontrollbereich (CVE-2026-27771), die laut Einschätzung viele Deployments betreffen konnte.
Für Administratoren ist das vor allem ein Signal: Wer Gitea betreibt, sollte Patchzyklen ernst nehmen und Security-Updates konsequent einplanen.
Fazit: Patchen, Logs prüfen, Tokens rotieren
Die Gitea Org-Mode Schwachstelle ist kritisch, weil sie ohne Login und ohne Repo-Schreibrechte zum Dateilesen führen kann—insbesondere, wenn ein öffentliches Repository vorhanden ist und gezielt Org-Mode-Markup über das Rendering-Ende geschickt wird. Der sichere Schritt ist klar: Upgrade auf Gitea 1.27.1.
Zusätzlich sollten Sie die Serverprotokolle prüfen und, falls Exposition wahrscheinlich ist, die empfohlenen Tokens und Schlüsselmaterialien rotieren sowie nach möglichen Hook-Manipulationen suchen. So schließen Sie die Lücke nicht nur technisch, sondern reduzieren auch Folgerisiken nach einer möglichen Ausnutzung.
Quelle: https://thehackernews.com/2026/08/critical-gitea-flaw-let-unauthenticated.html
