Mastodon Mastodon Mastodon Mastodon

Kritische Gitea-Schwachstelle erlaubt RCE über diffpatch-Endpoint

Foto des Autors

CyberSecureFox Editorial Team

Veröffentlicht:

Gitea hat eine kritische Schwachstelle für Remote Code Execution (CVE-2026-60004, CVSS 9.8) behoben, die es einem Benutzer mit Schreibrechten in einem Repository ermöglicht, über den API-Endpoint diffpatch einen ausführbaren Git-Hook einzuschleusen und beliebige Befehle im Namen des Gitea-Servicekontos auszuführen. Die Schwachstelle betrifft alle Versionen von 1.17 bis 1.27.1. Der Fix steht in Version 1.27.1 zur Verfügung. Proof-of-Concept-Exploitcode (PoC) ist bereits öffentlich, obwohl zum Zeitpunkt der Veröffentlichung noch keine bestätigten Ausnutzungen in realen Angriffen beobachtet wurden. Alle Administratoren von self-hosted Gitea-Installationen müssen umgehend aktualisieren.

Exploit-Mechanismus

Der verwundbare Endpoint POST /api/v1/repos/{owner}/{repo}/diffpatch wendet einen benutzerdefinierten Patch innerhalb eines gemeinsamen temporären bare-Klon des Repositories an. Laut offiziellem Gitea-Advisory rufen die verwundbaren Builds git apply mit den Flags --index, --recount, --cached und --binary auf. Ist Git in Version 2.32 oder höher vorhanden, wird zusätzlich das Flag -3 (three-way merge fallback) aktiviert.

Der Angriff basiert auf folgender Kette:

  1. Der Angreifer sendet denselben Patch zweimal und erzeugt damit eine Add/Add-Kollision.
  2. Der Three-way-Fallback-Mechanismus extrahiert den indizierten Pfad in den Working Tree, obwohl --cached verwendet wird.
  3. Da der temporäre Klon ein Bare-Repository ist, fällt sein Wurzelverzeichnis mit $GIT_DIR zusammen. Eine ausführbare Datei, die unter dem Pfad hooks/post-index-change abgelegt wird, landet unmittelbar im Git-Hooks-Verzeichnis.
  4. Git führt den Hook post-index-change beim Aktualisieren des Index automatisch aus – der Angreifer erhält dadurch die Ausführung beliebigen Codes.

Der PoC demonstriert den vollständigen Angriffsablauf ohne die Notwendigkeit einer Rückverbindung: Der Hook speichert die Befehlsausgabe in Git-Objekten, erstellt einen Branch mit dem Ergebnis, und der Angreifer ruft die Daten über authentifiziertes Smart HTTP ab.

Ausnutzungsbedingungen und Angriffsfläche

Formal erfordert der Endpoint Authentifizierung und Schreibrechte im Repository – die Route ruft reqToken() auf, das nicht autorisierte Anfragen verwirft. Allerdings lässt die Standardkonfiguration von Gitea die Registrierung offen, verlangt keine Bestätigung der E-Mail-Adresse oder manuelle Freigabe, markiert neue Benutzer nicht als eingeschränkt und setzt kein Limit für die Erstellung von Repositories. Auf einer unveränderten Installation kann sich ein externer Besucher selbst registrieren, ein Repository anlegen und so die erforderlichen Schreibrechte erlangen.

Die vollständigen Voraussetzungen für eine Ausnutzung:

  • Schreibrechte in einem Repository (erreichbar über offene Registrierung)
  • Git in Version 2.32 oder höher auf dem Server
  • Aktivierte diffpatch-Route
  • Beschreibbares und ausführbares temporäres Dateisystem

Folgen einer Kompromittierung

Eine erfolgreiche Ausnutzung verschafft dem Angreifer die Privilegien des Betriebssystemkontos, unter dem Gitea läuft. Laut Advisory kann dies, je nach Grad der Isolation der Instanz, zur Offenlegung folgender Daten führen:

  • Anwendungsgeheimnissen und Umgebungsvariablen
  • eingebundener Repositories
  • Zugangsdaten und Datenbankinhalten
  • OAuth-Tokens
  • verfügbarer interner Dienste im Netzwerk

Da Gitea häufig als zentraler Knoten für die Speicherung des Quellcodes einer Organisation eingesetzt wird, kann die Kompromittierung einer Instanz zum Einstiegspunkt für Angriffe auf die Lieferkette werden.

Offenlegung und Behebung im Detail

Die Chronologie der Ereignisse verdient besondere Beachtung. Der Fix wurde am 26. Juli 2026 gemergt und backported. Version 1.27.1 erschien am 27. Juli, und das Security-Advisory wurde am 28. Juli veröffentlicht. In den Release Notes ist die Korrektur jedoch im Abschnitt MISC als „refactor: git patch apply“ und nicht im Abschnitt SECURITY aufgeführt. Eine solche Kennzeichnung kann dazu führen, dass Administratoren, die ausschließlich Security-Fixes verfolgen, dieses kritische Update übersehen.

Der Kern der Behebung besteht darin, den Typ des temporären Klons von bare auf non-bare zu ändern. Ein Kommentar im Commit-Code weist ausdrücklich darauf hin, dass Git-Befehle mit dem Flag --index auf den Working Tree zugreifen können. In einem non-bare Klon fällt das Wurzelverzeichnis nicht mehr mit $GIT_DIR zusammen, wodurch die Kette zur Hook-Injektion unterbrochen wird.

Die Schwachstelle wurde vom Sicherheitsforscher Shai Rod (NightRang3r) entdeckt, der im Gitea-Advisory als Finder genannt wird. Neben der RCE wurde in Version 1.27.1 auch ein Problem mit File Inclusion im Org-mode-Renderer behoben: #+INCLUDE-Direktiven werden nun als normaler Text zurückgegeben, statt Dateien aus dem Server-Dateisystem zu lesen. Für dieses Problem hat Gitea kein separates Advisory oder CVE veröffentlicht.

Empfehlungen

  • Aktualisieren Sie umgehend alle self-hosted Gitea-Installationen auf Version 1.27.1. Nach Angaben von Gitea werden Cloud-Instanzen von Gitea Cloud automatisch aktualisiert.
  • Deaktivieren Sie die offene Registrierung als vorübergehende Maßnahme für die Dauer des Updates. Dies beseitigt den Angriffsweg für externe, nicht authentifizierte Benutzer, schützt jedoch nicht vor bestehenden Benutzern mit Schreibrechten.
  • Prüfen Sie die Git-Version auf dem Server: Die Ausnutzung erfordert Git 2.32+. Falls ein sofortiges Gitea-Update aus irgendwelchen Gründen nicht möglich ist, kann ein Downgrade von Git auf eine Version unter 2.32 als vorübergehender Workaround dienen (unter Berücksichtigung möglicher Nebenwirkungen).
  • Führen Sie eine Log-Analyse durch auf verdächtige Aufrufe des Endpoints /api/v1/repos/{owner}/{repo}/diffpatch, insbesondere auf wiederholte Anfragen mit identischem Patch-Inhalt.
  • Überprüfen Sie die Isolation des Gitea-Servicekontos: Beschränken Sie den Zugriff auf Secrets, Datenbanken und interne Dienste nach dem Prinzip der geringsten Privilegien.

Die Kombination aus CVSS 9.8, öffentlichem PoC, standardmäßig offener Registrierung und der wenig offensichtlichen Kennzeichnung des Fixes im Changelog macht CVE-2026-60004 zu einer der gefährlichsten Schwachstellen im Ökosystem self-hosted Git-Plattformen der letzten Zeit. Die einzig verlässliche Maßnahme ist das Update auf Gitea 1.27.1, gefolgt von einer Überprüfung der Registrierungskonfiguration und der Isolation der Instanz. Der Eintrag in der NVD bestätigt den kritischen Schweregrad der Schwachstelle.


CyberSecureFox Editorial Team

Die CyberSecureFox-Redaktion berichtet über Cybersecurity-News, Schwachstellen, Malware-Kampagnen, Ransomware-Aktivitäten, AI Security, Cloud Security und Security Advisories von Herstellern. Die Beiträge werden auf Grundlage von official advisories, CVE/NVD-Daten, CISA-Meldungen, Herstellerveröffentlichungen und öffentlichen Forschungsberichten erstellt. Artikel werden vor der Veröffentlichung geprüft und bei neuen Informationen aktualisiert.

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre, wie deine Kommentardaten verarbeitet werden.