Die Kurzfassung
Gitea, der populäre selbst gehostete Git-Dienst, weist eine kritische unauthentifizierte Schwachstelle zum beliebigen Lesen von Dateien auf — CVE-2026-59774, bewertet mit CVSS 9,8 — die es jedem ermöglicht, Dateien auf dem Server ohne Anmeldung zu lesen und diese zu Remote Code Execution zu verketten. Der Angriff erfordert nur ein öffentliches Repository und ein präpariertes Org-Mode-Dokument: eine Anfrage an Giteas Markup-Rendering-Endpunkt missbraucht die Org-Mode-Direktive #+INCLUDE, um beliebige Dateien über absolute Pfade einzubinden. Betroffen sind die Versionen 1.22.1 bis 1.27.0; die Lösung ist Gitea 1.27.1, das auch einen verwandten Codeausführungs-Fehler, CVE-2026-60004, behebt.
Wer Gitea als Teil seines CI/CD- und DevOps-Stacks selbst betreibt — viele Teams tun dies genau, um Quellcode von Drittanbieter-Clouds fernzuhalten — muss das noch am selben Tag patchen, nicht als Routine-Advisory behandeln. Die erste Datei, die ein Angreifer liest, ist Ihre Konfigurationsdatei — und die enthält die Schlüssel zu allem anderen.
Was ist passiert
Am 2. August 2026 veröffentlichte das Gitea-Projekt ein Sicherheitsadvisory und lieferte Version 1.27.1 aus, wobei alle Nutzer aufgefordert wurden, so schnell wie möglich zu aktualisieren. Das Hauptproblem, CVE-2026-59774, ist ein unauthentifiziertes beliebiges Dateilesen, unabhängig gemeldet von XBOW Security und Forscher Guido Leo (NightRang3r). Es trägt einen CVSS-Score von 9,8 und betrifft jedes Gitea-Release von 1.22.1 bis 1.27.0.
Die Schwachstelle liegt in Giteas Markup-Rendering-Funktion. Eine Anfrage an POST /{owner}/{repo}/markup rendert Inhalte wie README-Dateien. Die Route enthält Repository-Zuweisung und Reader-Prüfungen, aber ein anonymer Nutzer erfüllt diese Prüfungen für ein öffentliches Repository mit aktivierter Code-Einheit — eine sehr verbreitete Konfiguration. Wenn Gitea Org-Mode-Inhalte rendert, verarbeitet es die Direktive #+INCLUDE, und in den betroffenen Versionen löst diese Direktive absolute Dateisystempfade auf. Das praktische Ergebnis: präpariertes Org-Mode-Markup senden und beliebige Dateien zurücklesen, auf die das Gitea-Dienstkonto zugreifen kann.
Die technische Grundursache ist klein und lehrreich. Gitea 1.27.0 initialisierte die go-org-Parsing-Bibliothek mit org.New(), ersetzte jedoch nicht den Standard-Dateilese-Callback der Bibliothek, der auf ein einfaches ReadFile abbildet. Nichts beschränkte #+INCLUDE auf das Repository, sodass der Include-Mechanismus zu einem Path-Traversal-Lese-Primitiv wurde. Der Patch überschreibt diesen Callback; die Lösung ist Version 1.27.1 oder höher.
Wie ein Dateizugriff zu Codeausführung wird
Ein beliebiges Dateilesen ist auf einem Versionskontrollserver bereits ernst, weil die erste lesenswerte Datei Giteas eigene Konfiguration ist. Laut dem Advisory des Projekts eskaliert die Exposition in einer kurzen Kette: app.ini lesen, um den INTERNAL_TOKEN zu extrahieren, diesen Token verwenden, um über den internen Logger einen Git-Hook zu injizieren, und den Hook dann bei einem anonymen Clone auslösen. Das Endergebnis ist Codeausführung auf dem Host. Gitea 1.27.1 behebt auch eine direkt verwandte Schwachstelle, CVE-2026-60004, beschrieben als Remote Code Execution über die diffpatch-API durch Git-Hook-Installation — vom selben Forscher gemeldet.
Zum Zeitpunkt der ersten öffentlichen Writeups am 5. August 2026 war CVE-2026-59774 nicht in CISAs Known Exploited Vulnerabilities-Katalog aufgetaucht und kein unabhängiger Proof-of-Concept-Exploit wurde veröffentlicht. Das ist ein schwacher Trost. Das Dateilese-Verhalten wurde öffentlich vor dem formellen Advisory demonstriert, der Endpunkt ist trivial erreichbar, und der Eskalierungspfad ist dokumentiert. Für eine so günstig auszunutzende Schwachstelle in Infrastruktur, die Quellcode und Secrets enthält, ist „noch nicht in KEV" ein Planungsdetail, keine Entwarnung.
Teilweise durch eine KI entdeckt
Ein Detail liegt an der Schnittstelle zweier Themen, die wir verfolgen. Einer der zwei unabhängigen Melder von CVE-2026-59774 war XBOW, ein autonomes Offensive-Security-System, das Schwachstellen findet und validiert, ohne dass ein Mensch jeden Schritt steuert. Es ist ein konkretes Beispiel für einen umfassenderen Wandel: KI-Tooling komprimiert die Zeit, die benötigt wird, um Bugs zu entdecken, zu bestätigen und zu weaponisieren. Wenn dieselbe Klasse von Tools für Verteidiger und Angreifer gleichermaßen verfügbar ist, ist die sichere Annahme, dass eine frisch offengelegte, leicht erreichbare Schwachstelle schnell untersucht wird.
Das erfordert keine Panik; es erfordert Kadenz. Teams, die ein Inventar ihrer selbst gehosteten Entwickler-Tooling führen, Sicherheitsadvisories abonnieren und „kritisch, unauthentifiziert, internet-erreichbar" als beschleunigten Patch-Trigger behandeln, schließen dieses Fenster in Stunden. Teams, die erst herausfinden, welche internen Dienste sie betreiben, wenn einer gehackt wurde, werden das nicht. Ein regelmäßiges Sicherheitsaudit, das die Entwickler-Supply-Chain einschließt — Git-Server, CI-Runner, Artifact-Registries — ist der Ort, an dem diese blinden Flecken sichtbar werden, bevor ein Angreifer sie findet.
Was das für DACH-Softwareteams bedeutet
Gitea ist besonders bei Teams attraktiv, die Kontrolle wollen: Repositories auf eigener Infrastruktur, im eigenen Netzwerk, fernab von Drittanbieter-SaaS halten. Dieser Instinkt ist solide — und im DACH-Raum oft durch Datensouveränität und DSGVO-Anforderungen begründet. Doch er verlagert die Patch- und Härtungslast auf Sie. Ein selbst gehosteter Git-Server ist kein passiver Dateispeicher; er enthält Quellcode, Deploy-Keys, Webhook-Secrets und die Tokens, mit denen CI in die Produktion pushen kann. Ein unauthentifizierter Lesezugriff auf die Konfiguration dieses Servers ist ein Einstiegspunkt in die gesamte Delivery-Pipeline.
Der Compliance-Rahmen ist klar. Unter BSI-Grundschutz, DSGVO und SOC 2 ist eine ungepatchte, remote erreichbare Schwachstelle, die zu Codeausführung und Secret-Exposition führen kann, eine Kontrollücke mit Change-Management- und potenziell Breach-Notification-Implikationen. „Es war unser interner Git-Server" ist kein mildernder Faktor, wenn dieser Server erreichbar war und die Secrets, die er enthielt, Kundendaten oder Produktionssysteme berührten. Der pragmatische Schritt ist, selbst gehostetes Entwickler-Tooling in dieselbe Patch-SLA und Secrets-Hygiene-Disziplin einzubinden, die bereits für Produktionsdienste gilt.
Was jetzt zu tun ist
Dies ist ein Patch-dann-Exposition-annehmen-Vorfall. Die Reihenfolge ist wichtig: Das Upgrade stoppt neue Ausnutzung, aber das Rotieren der Secrets, die ein anfälliger Build hätte preisgeben können, macht jeden früheren Lesezugriff wertlos.
- Auf Gitea 1.27.1 oder höher aktualisieren. Dies schließt CVE-2026-59774 und den verwandten RCE-Fehler CVE-2026-60004. Jede Instanz patchen, einschließlich Staging- und vergessener interner Server.
- Exposition zuerst prüfen. Zugriffsprotokolle auf Anfragen an den
/{owner}/{repo}/markup-Endpunkt auf betroffenen Builds überprüfen und feststellen, ob Gitea von nicht vertrauenswürdigen Netzwerken oder dem Internet aus erreichbar war. - Was die Konfiguration preisgibt, rotieren. Den
INTERNAL_TOKENinapp.inineu generieren, dann Datenbankpasswörter, OAuth-Anwendungs-Secrets, JWT-Signierungsschlüssel, SMTP-Zugangsdaten und alle in der Konfiguration oder dem Dateisystem gespeicherten Integrations-Tokens rotieren. - Nach platzierten Hooks suchen. Da Dateilesen via Git-Hooks zu Codeausführung verkettet werden kann, Repositories und das Gitea-Datenverzeichnis auf unerwartete oder kürzlich geänderte Hooks inspizieren und eine bestätigte Exposition als Host-Kompromittierung behandeln.
- Aus dem offenen Internet entfernen. Gitea wo möglich hinter einem VPN oder einer Allowlist platzieren; Entwickler-Tooling muss selten öffentlich erreichbar sein, und die Reduzierung der Exposition verkleinert den Blast-Radius der nächsten Schwachstelle.
- Advisory-Feed einrichten. Gitea Release Notes abonnieren und „kritisches selbst gehostetes Dev-Tooling" zu einer beschleunigten Patch-SLA hinzufügen, damit die nächste 9,8 ein Same-Day-Event ist.
Das dauerhafte Signal von CVE-2026-59774 geht nicht um einen Bibliotheks-Callback. Es geht darum, dass selbst gehostete Entwicklerinfrastruktur Produktions-Niveau-Privilegien trägt und Produktions-Niveau-Betrieb verdient: ein bekanntes Inventar, einen Advisory-Feed, einen beschleunigten Patch-Pfad und Secrets, die eng genug eingeschränkt sind, dass das Lesen einer Konfigurationsdatei nicht die gesamte Pipeline entsperrt. Teams, die ihren Git-Server wie das Kronjuwel-System behandeln, das er ist, werden das in einem Nachmittag patchen und weitermachen.
Häufig gestellte Fragen
Was ist CVE-2026-59774 in Gitea?
CVE-2026-59774 ist eine kritische unauthentifizierte Schwachstelle zum beliebigen Lesen von Dateien in Gitea, dem selbst gehosteten Git-Dienst, bewertet mit CVSS 9,8. Ein Angreifer ohne Konto kann beliebige Dateien, auf die der Gitea-Dienstprozess zugreifen kann, auslesen, indem er präpariertes Org-Mode-Markup an den Markup-Rendering-Endpunkt eines öffentlichen Repositorys sendet. Betroffen sind Gitea-Versionen 1.22.1 bis 1.27.0; behoben in 1.27.1, das auch einen verwandten RCE-Fehler, CVE-2026-60004, behebt.
Wie kann eine Dateilese-Schwachstelle zu Remote Code Execution werden?
Laut Giteas Advisory kann das Dateilese-Primitiv zu Codeausführung gekettet werden. Ein Angreifer liest die Konfigurationsdatei app.ini aus, um den INTERNAL_TOKEN zu extrahieren, injiziert über den internen Logger einen Git-Hook und löst diesen Hook bei einem anonymen Clone aus. Das verwandte CVE-2026-60004 deckt Remote Code Execution über die diffpatch-API durch Git-Hook-Installation ab. Beide sind in Gitea 1.27.1 behoben, weshalb das Projekt alle zur sofortigen Aktualisierung auffordert.
Welche Gitea-Versionen sind betroffen und was ist die Lösung?
Gitea 1.22.1 bis 1.27.0 sind für CVE-2026-59774 anfällig. Die Lösung ist Gitea 1.27.1 oder höher. Die Grundursache ist, dass Gitea die go-org-Bibliothek ohne Überschreiben des Standard-Dateilese-Callbacks initialisierte, sodass der #+INCLUDE-Direktive absolute Dateisystempfade auflösen konnte. Das Upgrade ersetzt dieses Verhalten und schließt den Endpunkt für Path-Traversal.
Wir haben Gitea gepatcht. Reicht das?
Das Patchen stoppt weitere Ausnutzung, aber wenn ein anfälliger Build erreichbar war, sollte angenommen werden, dass Secrets bereits exponiert sein könnten. Zugriffsprotokolle auf Anfragen an den Markup-Endpunkt überprüfen, dann den INTERNAL_TOKEN in app.ini und alle anderen Zugangsdaten rotieren, die die Konfiguration oder das Server-Dateisystem preisgeben könnte: OAuth-Secrets, JWT-Signierungsschlüssel, Datenbankpasswörter, SMTP-Zugangsdaten und Integrations-Tokens. Da Dateilesen zu Codeausführung verkettet werden kann, eine bestätigte Exposition als Server-Kompromittierung behandeln und auf unerwartete Git-Hooks prüfen.
Warum ist eine KI-entdeckte Schwachstelle für unsere Patch-Kadenz relevant?
Einer der zwei unabhängigen Melder dieser Schwachstelle war XBOW, ein autonomes Offensive-Security-System. Da KI-Tools Bugs schneller finden und weaponisieren, schrumpft das Zeitfenster zwischen Offenlegung und Ausnutzung. Die dauerhafte Lektion ist operationeller Natur: ein Inventar selbst gehosteter Entwicklerinfrastruktur führen, kritische Advisories in eine beschleunigte Patch-SLA einbinden und Entwickler-Tooling wie Gitea nicht ohne Notwendigkeit direkt dem Internet aussetzen.
Quellen
Gitea — Release of 1.27.1 (Sicherheitsadvisory)
The Hacker News — Critical Gitea Flaw Let Unauthenticated Attackers Read Server Files via Org-Mode Markup
Cyber Security News — Critical Gitea Arbitrary File Read Vulnerability Enables RCE