Gitea CVE-2026-60004: diffpatch-Endpoint erlaubt Git-Hook-Planting und RCE — aktiv ausgenutzt, jetzt in der CISA-KEV

TL;DR — 90 Sekunden

Betroffen?

Gitea-Instanzen der Versionen 1.17 bis 1.27.0 mit erreichbarem diffpatch-API-Endpoint — praktisch jede Standardinstallation in diesem Versionsbereich, insbesondere mit offener Registrierung.

Risiko?

CVSS 3.1: 9.8 (Kritisch) — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Über eine Add/Add-Kollision beim Patch-Anwenden lässt sich ein bösartiger Git-Hook (hooks/post-index-change) platzieren, der mit den Rechten des Gitea-Dienstkontos ausgeführt wird — faktisch unauthentifizierte Remote-Code-Ausführung, da ein Angreifer sich bei offener Registrierung selbst ein Konto anlegen kann.

Sofortmaßnahme?

Auf Gitea 1.27.1 oder neuer aktualisieren. Zusätzlich DISABLE_REGISTRATION = true setzen, falls offene Registrierung nicht benötigt wird.

Empfehlung?

Sofort patchen — CISA hat die Lücke am 25.08.2026 in die KEV aufgenommen, mit einer Remediationsfrist für US-Bundesbehörden bis zum 28.08.2026. Aktive Ausnutzung mit Crypto-Mining-Payload ist dokumentiert.

Kritikalität?

kritisch — CVSS 9.8, aktiv ausgenutzt, in der CISA-KEV.

Was ist das Problem?

Der Endpoint /api/v1/repos/{owner}/{repo}/diffpatch dient eigentlich dazu, Patches gegen ein Repository zur Vorschau anzuwenden, ohne sie tatsächlich zu committen. Dafür wendet Gitea den eingereichten Patch intern gegen eine Bare-Clone-Kopie des Repositories an.

Reicht ein Angreifer denselben Patch zweimal ein, entsteht beim Anwenden eine sogenannte „Add/Add“-Kollision — ein Konflikt, bei dem beide Patch-Versionen versuchen, dieselbe neue Datei anzulegen. Diese Kollisionssituation lässt sich so präparieren, dass am Ende eine ausführbare Datei unter dem Pfad hooks/post-index-change im Repository landet — einem Git-Hook, der bei einer Index-Aktualisierung automatisch ausgeführt wird. Da Gitea diese Index-Operationen mit den Rechten des eigenen Dienstkontos durchführt, führt die nächste Index-Aktualisierung den vom Angreifer platzierten Code mit denselben Rechten aus wie der Gitea-Serverprozess selbst.

Der Clou dabei: Der CVSS-Vektor weist PR:N (keine Rechte erforderlich) aus, weil Gitea-Instanzen in der Standardkonfiguration offene Registrierung ohne E-Mail-Bestätigung oder Administrator-Freigabe erlauben. Ein Angreifer muss also lediglich ein eigenes Konto anlegen, ein eigenes Repository erstellen und dort die präparierten Patches gegen den diffpatch-Endpoint einreichen — bestehende Schreibrechte auf ein fremdes Repository sind nicht nötig.

Wer ist betroffen?

Installierte Version prüfen:

# über die Weboberfläche: Site-Administration → Übersicht → Gitea-Version
# oder per API:
curl -s ihre-gitea-instanz.example/api/v1/version

# oder direkt auf dem Server (Binary-Installation):
gitea --version

Auswirkungen

Erfolgreiche Ausnutzung liefert Codeausführung mit den Rechten des Gitea-Dienstkontos auf dem Host-System — nicht nur innerhalb des angegriffenen Repositories. Da Gitea häufig als zentrale Code- und CI/CD-Quelle betrieben wird, reicht der Blast Radius typischerweise deutlich weiter als ein einzelnes Projekt: Zugriff auf andere Repositories auf derselben Instanz (inklusive privater Repos, sofern das Dienstkonto entsprechende Dateisystemrechte hat), auf hinterlegte CI/CD-Secrets und Deploy-Keys, sowie potenziell laterale Bewegung in angebundene Build- und Deployment-Infrastruktur.

Die bislang dokumentierten Angriffe setzen einen Crypto-Miner-Dropper nach: Ein Skript leert relevante Umgebungsvariablen (LD_PRELOAD, LD_LIBRARY_PATH), beendet konkurrierende Hochlast-Prozesse, lädt eine architekturspezifische Payload nach, führt sie aus und entfernt anschließend Spuren. Die resultierende Mining-Last hat in beobachteten Fällen über 70 % der Server-CPU-Kapazität gebunden — ein vergleichsweise „harmloser“, aber gut sichtbarer Missbrauch. Nichts an der Schwachstelle selbst beschränkt einen Angreifer jedoch auf Crypto-Mining; dieselbe Codeausführung erlaubt ebenso gezielten Datendiebstahl oder das Einschleusen von Hintertüren in gehostete Projekte.

Mitigation / Sofortmaßnahmen

Operativer Entscheidungsblock

• Jetzt handeln, wenn … Ihre Gitea-Instanz eine Version zwischen 1.17 und 1.27.0 fährt und der API-Endpoint erreichbar ist — unabhängig davon, ob die Instanz öffentlich oder nur intern erreichbar ist.
• Mit Priorität prüfen, wenn … offene Registrierung aktiv ist und Sie nicht genau wissen, wer sich in der Vergangenheit registriert hat.
• Im nächsten regulären Fenster, wenn … bereits auf 1.27.1 oder neuer aktualisiert wurde.

Schritt 1 — auf Gitea 1.27.1 oder neuer aktualisieren

# Versionsstand prüfen
gitea --version

# Docker-Betrieb: aktuelles Image ziehen und Container neu erstellen
docker pull gitea/gitea:1.27.1
docker compose up -d gitea

# Binary-Installation: offizielles Release von codeberg.org/gitea/gitea oder
# gitea.com/gitea/gitea beziehen und gemäß offizieller Upgrade-Anleitung einspielen
# (vor dem Upgrade: Datenbank- und Repository-Backup nicht vergessen)

Schritt 2 — offene Registrierung schließen

# in app.ini, Sektion [service]:
[service]
DISABLE_REGISTRATION = true

# alternativ, falls Registrierung grundsätzlich gewünscht ist:
REGISTER_EMAIL_CONFIRM = true
# und manuelle Admin-Freigabe neuer Konten in Betracht ziehen

Diese Härtung schließt die Lücke nicht, entzieht einem opportunistischen Angreifer aber den einfachsten Weg zu einem Konto — wichtig auch als generelle Absicherung gegen künftige Schwachstellen dieser Art.

Schritt 3 — API-Exposition prüfen

# Faustregel: Gitea-Instanzen mit sensiblen Repositories nicht ungeschützt aus dem
# öffentlichen Internet erreichbar machen; API-Zugriff nach Möglichkeit auf bekannte
# Netzbereiche oder über ein VPN/Zero-Trust-Gateway beschränken

Detection / Prüfung

Repository-Hooks auf unautorisierte Dateien prüfen

# auf dem Gitea-Server: alle Repository-Verzeichnisse nach verdächtigen
# post-index-change-Hooks durchsuchen
find /data/gitea-repositories -type f -name "post-index-change" -exec ls -la {} \;

# Inhalt verdächtiger Treffer vor dem Löschen sichern und manuell prüfen
cat /pfad/zum/repo.git/hooks/post-index-change

API-Logs auf wiederholte diffpatch-Anfragen prüfen

# in den Gitea-Access-Logs nach ungewöhnlich häufigen Aufrufen desselben
# Kontos gegen den diffpatch-Endpoint suchen
grep "diffpatch" /var/log/gitea/access.log | awk '{print $1, $7}' | sort | uniq -c | sort -rn | head -20

Neu registrierte Konten mit ungewöhnlichem Verhalten

Ein typisches Muster: ein frisch registriertes Konto legt unmittelbar danach ein Repository an und wird anschließend inaktiv. Das lässt sich über die Admin-Oberfläche (Site-Administration → Nutzerkonten, sortiert nach Registrierungsdatum) oder per API abgleichen.

Auffällige CPU-Last ohne erklärbare Build-Aktivität

# laufende Prozesse mit ungewöhnlich hoher CPU-Last identifizieren
top -b -n 1 | head -20

# Prozessbaum des Gitea-Dienstkontos gezielt prüfen
ps -u git -o pid,ppid,cmd,%cpu --sort=-%cpu | head -10

CISA und die zitierten Quellen nennen diese vier Muster — unautorisierte Dateien im hooks/-Verzeichnis, gehäufte diffpatch-Aufrufe, Registrieren-dann-inaktiv-Konten und unerklärte CPU-Spitzen — als konkrete Indikatoren für diese Kampagne.

Betreiberempfehlung

Mid-Market

Sofort auf 1.27.1 aktualisieren und offene Registrierung schließen — CISA-KEV-Aufnahme und dokumentierte aktive Ausnutzung rechtfertigen ein Notfall-Update außerhalb des regulären Wartungsfensters.

Enterprise / Multi-Repo-Betreiber

Zusätzlich zum Update: alle Repository-Verzeichnisse auf unautorisierte post-index-change-Hooks prüfen, Registrierungshistorie der letzten Wochen auf Registrieren-dann-inaktiv-Muster durchsehen, und CI/CD-Secrets sowie Deploy-Keys rotieren, falls Hinweise auf Kompromittierung vorliegen. Gitea-Instanzen, die als zentrale Quelle für Build-Pipelines dienen, verdienen dabei besondere Aufmerksamkeit.

Behörden / regulierte Branchen

US-Bundesbehörden (FCEB) mussten laut CISA-KEV-Eintrag bis zum 28.08.2026 remediieren. Auch ohne direkte Meldepflicht ist dieser Zeitrahmen ein realistischer Maßstab für die Dringlichkeit bei jeder Organisation mit erhöhtem Schutzbedarf, die selbst gehostete Gitea-Instanzen betreibt.

Entscheidungsblock

Heute handeln, wenn: eine Gitea-Instanz der Versionen 1.17–1.27.0 produktiv läuft, unabhängig von öffentlicher oder interner Erreichbarkeit. Beobachten genügt, wenn: bereits auf 1.27.1 aktualisiert, offene Registrierung deaktiviert und keine Auffälligkeiten bei Hooks, Logs oder CPU-Last festgestellt wurden.

Fazit

CVE-2026-60004 ist ein Lehrstück dafür, wie eine eigentlich harmlose Vorschau-Funktion (Patch-Preview ohne Commit) über einen Kollisionsfall beim Datei-Anlegen zu einer vollwertigen RCE-Kette wird — und wie sehr eine bequeme Standardeinstellung wie offene Registrierung die praktische Ausnutzbarkeit einer Schwachstelle erhöhen kann. Gitea wird häufig gerade von Teams betrieben, die bewusst von größeren SaaS-Plattformen weg zu selbst gehosteten Lösungen wechseln — diese Selbstverantwortung schließt das zeitnahe Einspielen von Sicherheitsupdates ausdrücklich ein. Mit CVSS 9.8, bestätigter aktiver Ausnutzung und CISA-KEV-Aufnahme gibt es hier keinen Interpretationsspielraum: patchen, Registrierung härten, Repository-Hooks prüfen.

Quellen

• The Hacker News — Critical Gitea RCE Actively Exploited as Reported Attack Drops Miner-Like Payload
• BleepingComputer — Over 8,300 Gitea servers vulnerable to code execution attacks (28.08.2026)
• Zero Day Hub — Gitea RCE: CVE-2026-60004 Exploited in the Wild (26.08.2026)
• GBHackers — Critical Gitea Flaw Lets Unauthenticated Attackers Read Server Files and Execute Code
• CISA — Known Exploited Vulnerabilities Catalog
• Gitea — offizielle Releases auf GitHub