Folgen Eine kritische Remote-Code-Ausführungs-Schwachstelle in Gitea hat sich weniger als einen Monat nach Verfügbarkeit eines Patches von der Offenlegung zur aktiven Ausnutzung entwickelt. Als CVE-2026-60004 verfolgt und mit 9,8 auf der CVSS-Skala bewertet, ermöglicht der Fehler einem Angreifer mit gewöhnlichem Repository-Schreibzugriff, einen ausführbaren Git-Hook zu platzieren und beliebige Shell-Befehle mit den Privilegien des Gitea-Dienstkontos auszuführen.
Am 25. August 2026 fügte die US-amerikanische Cybersicherheits- und Infrastruktursicherheitsbehörde (CISA) die ausgenutzte Gitea-Schwachstelle zu ihrem Katalog Bekannter Ausgenutzter Schwachstellen (KEV) hinzu und bestätigte, dass Angriffe in freier Wildbahn stattfinden. Bundeszivile Agenturen wurden angewiesen, betroffene Installationen bis zum 28. August 2026 zu beheben.
Das Problem wird besonders gefährlich, weil Gitea standardmäßig offene Registrierung ermöglicht. Obwohl die Ausnutzung technisch ein authentifiziertes Konto mit Repository-Schreibberechtigungen erfordert, könnte ein externer Angreifer in der Lage sein, ein Konto zu erstellen, ein Repository zu erstellen und diese Berechtigungen zu erlangen, ohne im Besitz gestohlener Anmeldedaten zu sein.
Ein öffentlich gemeldeter Angriff gegen einen anfälligen Server führte zur Bereitstellung eines Droppers, der sich durch Kryptowährungs-Mining-Verhalten auszeichnete. Der Vorfall unterstreicht, warum die in freier Wildbahn aktiv ausgenutzte kritische Gitea-RCE als eine dringende Priorität für die Behebung internetnaher selbstgehosteter Entwicklungsinfrastruktur behandelt werden sollte.
CVE-2026-60004-Analyse
Die Schwachstelle wird als CWE-94, unzureichende Kontrolle bei der Generierung von Code, klassifiziert und befindet sich in der diffpatch-Funktionalität von Gitea. Der betroffene API-Endpunkt wendet benutzergelieferte Patches in einem temporären Git-Repository an. Unter anfälligen Bedingungen kann ein Angreifer diesen Prozess so manipulieren, dass Repository-kontrollierter Inhalt zu einem ausführbaren Git-Hook wird, anstatt zu einer normalen Repository-Datei.
Die wichtigen Details zu CVE-2026-60004 betreffen, wie Gitea das temporäre Repository erstellte, das zum Verarbeiten von Patches verwendet wurde. Anfällige Versionen verwendeten einen nackten Git-Klon, bei dem das Repository-Verzeichnis selbst als internes Datenverzeichnis von Git fungiert. In Kombination mit Gits Patch-Verarbeitungsverhalten konnte speziell konstruierter Repository-Inhalt daher das Hook-Verzeichnis erreichen und ausführbar werden.
Ein Angreifer mit Schreibzugriff kann bösartige Patch-Inhalte an die diffpatch-API übermitteln. Durch das Auslösen eines Konflikt-Patch-Zustands kann Gits Drei-Wege-Verarbeitung dazu führen, dass eine vom Angreifer kontrollierte ausführbare Datei als Post-Index-Change-Hook materialisiert wird. Git führt diesen Hook dann während Repository-Operationen aus, was zur Befehlsausführung als Betriebssystemkonto führt, das Gitea ausführt.
CVE-2026-60004 betrifft Gitea 1.17 und spätere Veröffentlichungen bis Version 1.27.1. Gitea 1.27.1, veröffentlicht am 27. Juli 2026, behebt das Problem, indem das betroffene temporäre Klon-Verzeichnis von einem nackten auf ein nicht-nacktes Repository umgestellt wird, wodurch verhindert wird, dass Angreifer-kontrollierte Pfade als ausführbare Git-Hooks interpretiert werden.
Erfolgreiche Ausnutzung erfordert Repository-Schreibzugriff. Die Standardeinstellungen von Gitea schwächen jedoch dieses Erfordernis erheblich ab: Die Registrierung ist normalerweise aktiviert, Benutzer benötigen nicht notwendigerweise Administratorgenehmigungen oder E-Mail-Bestätigungen, und neu registrierte Benutzer können Repositories erstellen. Ein Angreifer, der auf eine unveränderte internetnahe Installation abzielt, könnte daher die erforderlichen Berechtigungen einfach durch das Erstellen eines neuen Kontos erfüllen.
Zusätzliche Ausnutzungsbedingungen, die in der technischen Recherche identifiziert wurden, umfassen eine serverseitige Git-Version, die das relevante Drei-Wege-Fallback-Verhalten unterstützt, Zugriff auf den diffpatch-Endpunkt und ein temporäres Dateisystem, in dem der Gitea-Dienst Dateien schreiben und ausführen kann. Diese Anforderungen bedeuten, dass nicht jede anfällige Installation notwendigerweise genau durch dieselbe Kette ausnutzbar ist, aber Standardkonfigurationen können einen praktischen Weg bieten.
Sobald beliebige Befehle unter dem Gitea-Dienstkonto ausgeführt werden, erstreckt sich die Auswirkung weit über ein einzelnes Repository hinaus. Abhängig davon, wie die Umgebung konfiguriert ist, kann ein Angreifer Zugriff auf private Repositories, Datenbankanmeldeinformationen, OAuth-Geheimnisse, Anwendungs-Konfigurationen, Umgebungsvariablen, CI/CD-Anmeldeinformationen, Paketregister oder interne Dienste, die vom Gitea-Host erreichbar sind, erhalten.
Für Organisationen, die Gitea als Teil von Softwareentwicklungs- und Bereitstellungs-Workflows verwenden, entsteht dadurch auch ein potenzielles Risiko für die Lieferkette. Der Kompromiss einer Quellcode-Verwaltungsplattform kann proprietären Code und Bereitstellungsgeheimnisse offenlegen und Gelegenheiten bieten, Repositories zu ändern oder gestohlene Anmeldeinformationen zu nutzen, um in CI/CD- und Produktionsinfrastrukturen vorzudringen.
Der Sicherheitsforscher Shai Rod, auch bekannt als NightRang3r, entdeckte und meldete die Schwachstelle. Gitea veröffentlichte die Version 1.27.1 am 27. Juli, gefolgt von dem formellen Sicherheitsbericht am 28. Juli. Das Problem hatte zunächst keine bestätigten Ausnutzungsberichte, aber das änderte sich, als CISA es am 25. August in den KEV-Katalog aufnahm.
Ein öffentliches CVE-2026-60004 Proof-of-Concept ist seit der Offenlegung der Schwachstelle verfügbar, was den erforderlichen Aufwand, die zugrunde liegende Angriffstechnik zu verstehen und nachzubilden, erheblich reduziert. Öffentliche Sicherheitstools haben auch Erkennungsvorlagen für anfällige Instanzen hinzugefügt, was die Wahrscheinlichkeit erhöht, dass Angreifer exponierte Server in großem Umfang identifizieren können.
Die Hacker News dokumentierten auch einen realen Vorfall mit einem internetnahen Gitea-Server mit aktivierter offener Registrierung. Laut Administrator erreichte der Angreifer den anfälligen Dienst über HTTPS, schuf die Bedingungen für die Ausnutzung und führte einen Dropper aus, der beträchtliche CPU-Ressourcen verbrauchte.
Der Dropper löschte bestimmte bibliotheksbezogene Umgebungsvariablen, suchte nach Prozessen, die erhebliche CPU-Ressourcen verbrauchten, versuchte konkurrierende Prozesse zu beenden, lud ein zu der Host-Architektur passendes Payload herunter, führte es aus und entfernte dann die heruntergeladene Datei. Der Administrator erlangte nicht genügend Beweise, um einen bestimmten Kryptowährungs-Miner, eine Wallet, einen Mining-Pool oder einen Bedrohungsakteur zu identifizieren, daher sollte das Payload derzeit als miner-ähnlich beschrieben werden, anstatt es einer bekannten Krypto-Jacking-Familie zuzuschreiben.
Es bleibt unklar, ob dieser spezifische Angriff dazu führte, dass CISA die Schwachstelle zu KEV hinzufügte oder ob die Behörde separate Ausnutzungskampagnen beobachtet hat. Weder CISA noch die beiden zitierten Berichte haben die breitere Aktivität öffentlich einem bekannten Bedrohungsakteur zugeschrieben.
Es wurde kein autoritatives Set von kampagnenweiten CVE-2026-60004 IOCs veröffentlicht. Verteidiger sollten sich daher auf verhaltensbezogene Beweise wie verdächtige Kontenerstellung, ungewöhnliche Aufrufe der diffpatch-API, unerwartete Git-Hooks, vom Gitea-Dienst gestartete Prozesse und anomale CPU- oder ausgehende Netzwerkaktivitäten verlassen.
CVE-2026-60004-Abmilderung
Organisationen, die selbst gehostete Gitea nutzen, sollten sofort auf Version 1.27.1 oder später aktualisieren. Gitea-Cloud-Umgebungen waren geplant, um das Update automatisch zu erhalten, während Administratoren von selbst verwalteten Installationen verantwortlich sind, die gepatchte Version selbst anzuwenden.
Da die Ausnutzung nun in freier Wildbahn bestätigt ist, sollte das Patchen nicht bis zum nächsten routinemäßigen Wartungsfenster verzögert werden. Die Aufnahme von CISA in KEV stellt einen starken Beweis dafür dar, dass die Schwachstelle ein unmittelbares operatives Risiko darstellt, wobei US-Bundeszivilagenturen verpflichtet sind, sie bis zum 28. August 2026 zu beheben.
Organisationen, die nicht sofort patchen können, sollten öffentliche Registrierung deaktivieren, wenn sie nicht benötigt wird. Durch das Setzen der Registrierung auf den Modus „Administrator-kontrolliert“ wird verhindert, dass ein nicht authentifizierter Internetbenutzer einfach ein Konto und ein Repository erstellt, um den für den Exploit erforderlichen Schreibzugriff zu erhalten. Diese Maßnahme verringert die Exposition, behebt die Schwachstelle jedoch nicht, da bestehende Benutzer mit Repository-Schreibberechtigungen weiterhin auf die anfällige Funktionalität zugreifen können.
Administratoren sollten zusätzlich die Erstellung von Repositories und Schreibberechtigungen einschränken, externen Zugriff auf Gitea nach Möglichkeit reduzieren und vermeiden, Entwicklungsinfrastruktur direkt dem Internet auszusetzen, es sei denn, es besteht eine eindeutige geschäftliche Notwendigkeit.
CVE-2026-60004-Erkennung sollte beginnen, indem alle Gitea-Installationen identifiziert, ihre genauen Versionen überprüft und festgestellt wird, ob die öffentliche Registrierung aktiviert war, während der Server eine betroffene Version lief. Internetnahe Instanzen, die anonymen Besuchern die Registrierung von Konten ermöglichten, verdienen höchste Priorität bei der Untersuchung.
Um Versuche der Ausnutzung von CVE-2026-60004 und Aktivitäten nach dem Kompromiss zu erkennen, sollten Verteidiger die Telemetrie von Gitea, der API, dem Betriebssystem und dem Netzwerk überprüfen auf:
- – Wiederholte oder unerwartete Anfragen an /api/v1/repos/{owner}/{repo}/diffpatch
- – Neu erstellte Konten, gefolgt von schneller Repository-Erstellung und Patch-Operationen
- – Shells oder unbekannte Prozesse, die vom Gitea-Dienstkonto gestartet werden
- – Ungewöhnliche anhaltende CPU-Auslastung auf Gitea-Hosts
- – Unerwartete Downloads oder Ausführungen aus temporären Verzeichnissen
- – Neue ausgehende Verbindungen, die von Gitea oder dessen untergeordneten Prozessen ausgehen
- – Unautorisierte Repository-Änderungen
- – Unerwarteter Zugriff auf Anwendungs-Konfiguration, Anmeldeinformationen oder Geheimnisse
Das Vorhandensein dieser Verhaltensweisen beweist nicht eigenständig eine Ausnutzung, aber Kombinationen wie Neuanmeldung eines Kontos gefolgt von Repository-Erstellung, diffpatch-Anfragen und neuen untergeordneten Prozessen sollten dringend untersucht werden.
Administratoren sollten auch Konten überprüfen, die erstellt wurden, während die anfällige Version exponiert war. Unbekannte Benutzer, Repositories, die kurz nach der Registrierung erstellt wurden, und Konten, die sofort API-Operationen durchführten, können helfen, Ausnutzungsversuche zu identifizieren, die vor dem Patchen des Servers aufgetreten sind.
Der CVE-2026-60004-Mitigation-Prozess sollte über die Installation der Version 1.27.1 hinausgehen, wenn ein Kompromiss vermutet wird. Da eine erfolgreiche Ausnutzung Codeausführung mit den Privilegien des Gitea-Betriebssystembenutzers ermöglicht, sollten Sicherheitsteams den betroffenen Host als potenziell kompromittiert behandeln und zugängliche Geheimnisse und verbundene Systeme untersuchen.
Vorfallsuntersucher sollten Datenbankanmeldeinformationen, OAuth- und API-Token, CI/CD-Geheimnisse, SSH-Schlüssel, Bereitstellungsanmeldeinformationen und andere sensible Materialien, auf die Gitea zugreifen kann, rotieren, wenn Beweise darauf hinweisen, dass eine Ausführung von beliebigem Code stattfand. Private Repositories sollten auch auf unautorisierte Änderungen geprüft und verbundene Build- oder Bereitstellungssysteme auf seitwärts gerichtete Bewegungen untersucht werden.
CVE-2026-60004 zeigt, wie sich eine Schwachstelle in der Entwicklungsinfrastruktur schnell von einem Softwarefehler zu einem aktiven Kompromisspfad entwickeln kann. Mit öffentlichen Exploits-Informationen verfügbar und bestätigter Ausnutzung sollten Organisationen mit anfälligen selbstgehosteten Gitea-Instanzen sowohl das Patchen als auch die rückblickende Bedrohungsjagd priorisieren.
FAQ
Was ist CVE-2026-60004 und wie funktioniert es?
CVE-2026-60004 ist eine kritische Code-Injektions-Schwachstelle in der diffpatch-API von Gitea. Ein Angreifer mit Repository-Schreibzugriff kann bösartige Patch-Inhalte einreichen, die dazu führen, dass ein ausführbarer Git-Hook installiert und ausgeführt wird, wodurch beliebige Shell-Befehle als der Gitea-Betriebssystembenutzer ausgeführt werden können. Die standardmäßige offene Registrierung kann einem externen Angreifer ermöglichen, die erforderlichen Repository-Berechtigungen einfach durch Erstellung eines Kontos zu erlangen.
Wann wurde CVE-2026-60004 erstmals entdeckt?
Das genaue private Entdeckungsdatum wurde nicht öffentlich bekannt gegeben. Gitea gibt an, dass der Sicherheitsforscher Shai Rod, auch bekannt als NightRang3r, das Problem gemeldet hat. Die Version 1.27.1, die den Fix enthält, wurde am 27. Juli 2026 veröffentlicht und der Sicherheitsbericht wurde am 28. Juli veröffentlicht. CISA bestätigte die aktive Ausnutzung, indem es den Fehler am 25. August in seinen KEV-Katalog aufnahm.
Welche Auswirkungen hat CVE-2026-60004 auf Systeme?
Erfolgreiche Ausnutzung ermöglicht es, beliebige Befehle mit den Privilegien des Gitea-Dienstkontos auszuführen. Dies kann Quellcode-Repositories, Anwendungsgeheimnisse, Datenbankanmeldeinformationen, OAuth-Material, CI/CD-Anmeldeinformationen und andere vom kompromittierten Server zugängliche Ressourcen offenlegen. Angreifer können auch Malware bereitstellen oder den Gitea-Host als Ausgangspunkt für weitere Eindringlinge nutzen.
Kann CVE-2026-60004 mich im Jahr 2026 noch betreffen?
Ja. Jede selbst gehostete Gitea-Installation, die Version 1.17 bis 1.27.0 ausführt, bleibt verwundbar. Das Risiko ist jetzt besonders dringend, da CISA die aktive Ausnutzung bestätigt hat und mindestens ein öffentlich beschriebener Einbruch den Fehler scheinbar zum Bereitstellen eines miner-ähnlichen Payload nutzte.
Wie kann ich mich vor CVE-2026-60004 schützen?
Aktualisieren Sie Gitea sofort auf Version 1.27.1 oder neuer. Deaktivieren Sie die offene Registrierung, wenn sie nicht benötigt wird, beschränken Sie die Erstellung von Repositories und den Schreibzugriff und überprüfen Sie die historische API-Aktivität auf verdächtige diffpatch-Anfragen. Wenn eine Ausnutzung vermutet wird, untersuchen Sie den Host auf bösartige Git-Hooks und unerwartete Prozesse und rotieren Sie Geheimnisse, auf die das Gitea-Dienstkonto zugreifen kann.
