Im Zentrum steht der Endpunkt POST /api/v1/repos/{owner}/{repo}/diffpatch. Laut Giteas Sicherheitshinweis wird darüber ein übermittelter Patch in einem gemeinsam genutzten temporären Bare-Clone angewendet. Verwundbare Versionen rufen dabei git apply mit den Optionen –index, –recount, –cached und –binary auf; auf Servern mit Git 2.32 oder neuer kommt zusätzlich die Drei-Wege-Ausweichoption -3 hinzu.

Genau diese Kombination macht den Fehler ausnutzbar. Ein Angreifer sendet denselben Patch zweimal, um einen Add/Add-Konflikt zu erzeugen. Die Drei-Wege-Ausweichlogik checkt den indizierten Pfad dann aus, obwohl die Operation mit –cached läuft. Weil der temporäre Clone als Bare-Repository angelegt ist, entspricht dessen Wurzel $GIT_DIR. Eine ausführbare Datei unter hooks/post-index-change landet so direkt im Hook-Verzeichnis von Git und wird beim Aktualisieren des Index ausgeführt.

Der von Gitea erwähnte Proof of Concept meldet sich mit einem normalen Konto an, erstellt ein initialisiertes privates Repository, übermittelt den bösartigen Patch zweimal und ruft anschließend die Befehlsausgabe ab. Dafür ist kein ausgehender Rückkanal nötig. Der Hook speichert die Ausgabe in Git-Objekten, legt einen Branch mit dem Ergebnis an und ermöglicht dem Angreifer den Abruf über authentifiziertes Smart HTTP.

Gitea zufolge führt eine erfolgreiche Ausnutzung Befehle mit den Rechten des Betriebssystemkontos von Gitea aus. Je nach Isolation der Instanz könnten dadurch Anwendungs- und Umgebungsgeheimnisse, eingehängte Repositories, Datenbankzugangsdaten und -inhalte, OAuth-Zugangsdaten sowie erreichbare interne Dienste offengelegt werden. Voraussetzung für den Angriff sind allerdings Schreibrechte auf ein Repository, Git 2.32 oder neuer, ein aktivierter diffpatch-Endpunkt sowie ein beschreibbares und ausführbares temporäres Dateisystem.

Dass sich die nötigen Schreibrechte unter Umständen leicht beschaffen lassen, liegt laut Quelltext an der Standardkonfiguration des Projekts. Die betroffene Route ruft reqToken() auf und weist Anfragen ohne angemeldeten Benutzer zurück. Standardmäßig lässt Gitea jedoch Registrierungen offen, verlangt weder E-Mail noch manuelle Freigabe, markiert neue Benutzer nicht als eingeschränkt und setzt keine Vorgabe für die Zahl neu anlegbarer Repositories. Das Abschalten der offenen Registrierung kann laut Hersteller zwar den öffentlichen Weg zur Kontoerstellung unterbinden, behebt die Schwachstelle aber nicht und schützt auch nicht vor bestehenden Benutzern mit Schreibrechten.

Die eigentliche Korrektur besteht darin, den temporären Clone von Bare auf Non-Bare umzustellen. Ein Code-Kommentar warnt ausdrücklich davor, dass Git-Befehle mit –index auf den Arbeitsbaum zugreifen können. Die Änderung wurde am 26. Juli zusammengeführt und zurückportiert. Version 1.27.1 erschien am 27. Juli, der Sicherheitshinweis folgte am 28. Juli. In den Versionshinweisen war die Änderung allerdings nicht unter „Sicherheit“, sondern unter „Verschiedenes“ als „Refaktorierung: Git-Patch-Anwendung“ aufgeführt.

Gemeldet wurde die Lücke von dem Sicherheitsforscher Shai Rod, der unter dem Namen NightRang3r auftritt; Gitea nennt NightRang3r im Sicherheitshinweis ausdrücklich als Melder. Rod hatte die RCE vorab zusammen mit einem separaten Datei-Inklusionsproblem vorgestellt, bei dem ein Proof of Concept die Datei /etc/passwd von einem Host mit Gitea 1.27.0 abrief. Dieses Problem scheint einer weiteren in 1.27.1 enthaltenen Änderung zu entsprechen: Gitea änderte den Org-Mode-Renderer so, dass Pfade in #+INCLUDE als Klartext zurückgegeben statt aus dem Dateisystem des Servers gelesen werden. Einen separaten Sicherheitshinweis oder eine eigene CVE hat Gitea dafür bislang nicht veröffentlicht. Bis zum 29. Juli 2026 meldete keine der zitierten Primärquellen, ob CVE-2026-60004 vor oder nach der Verfügbarkeit von 1.27.1 bereits ausgenutzt wurde.