Gitea unter Beschuss — Kritische CVEs 2026

Eine RCE-Lücke mit öffentlichem PoC, ein Docker-Auth-Bypass unter aktiver Ausnutzung und fünf weitere Fixes: Alles was Betreiber von Gitea 1.25 und 1.26 jetzt wissen müssen.

17. August 2026 · CVE-2026-60004 · CVE-2026-58443 · CVE-2026-20896 · Security · Self-Hosting · Git

Handlungsbedarf — CVE-2026-60004

Gitea 1.17 bis 1.27.0 ist durch eine kritische RCE-Schwachstelle (CVSS 9.8) mit öffentlichem PoC betroffen. Wer Gitea mit offener Registrierung betreibt, ist ohne vorhandene Credentials ausnutzbar. Fix: Upgrade auf 1.27.1.

Im Sommer 2026 haben sich mehrere kritische Sicherheitslücken in Gitea angesammelt. Die gefährlichste davon — CVE-2026-60004 — ermöglicht Remote Code Execution über eine manipulierte Patch-Anfrage und hat seit dem 28. Juli 2026 einen öffentlichen Proof-of-Concept. Wer noch auf einer Version vor 1.27.1 läuft, hat ein zeitkritisches Problem.

CVE-Übersicht ab Version 1.25

CVE	CVSS	Beschreibung	Fix ab	Status (1.25.4)
CVE-2026-60004	9.8	RCE via Git Hook Injection (diffpatch)	1.27.1	Betroffen
CVE-2026-58443	9.6	Public-Token pushes in private Repos	1.27.0	Betroffen
CVE-2026-20896	9.8	Docker Auth-Bypass via HTTP-Header	1.26.3	Nur Docker + Reverse-Proxy-Auth
CVE-2026-25779	6.1	Redirect-Bypass via Backslash-Pfade	1.25.5	Betroffen
CVE-2026-27660	5.4	Fehlende Berechtigungsprüfung bei Release-Drafts	1.25.5	Betroffen
CVE-2026-27657	6.5	Nutzer konnte fremde primäre E-Mail ändern	1.25.5	Betroffen
CVE-2026-26232	5.9	OAuth2 Authorization Code: fehlendes Expiry/Reuse	1.25.5	Betroffen
CVE-2026-24690	5.4	Unzureichende Berechtigungsprüfung beim PR-Rebase	1.25.5	Betroffen

CVE-2026-60004 — Remote Code Execution (CVSS 9.8)

Die gefährlichste Lücke sitzt im diffpatch-Endpoint: Gitea verarbeitet Repository-Patches über interne Git-Kommandos. Wer denselben speziell präparierten Patch zweimal einreicht, kann in einem temporären Bare-Clone einen bösartigen Git Hook platzieren — und damit beliebige Shell-Kommandos als Gitea-Service-Account ausführen.

Kein Vorwissen nötig

Gitea erlaubt standardmäßig offene Registrierung (DISABLE_REGISTRATION = false). Ein vollständig externer Angreifer kann sich ein Konto anlegen, ein Repository erstellen und die Lücke direkt ausnutzen — ohne jegliche Vorauthentifizierung. Ein öffentlicher PoC existiert seit dem 28. Juli 2026.

Betroffen: Gitea 1.17.0 bis 1.27.0
Fix: Gitea 1.27.1
Kein Backport in die 1.25.x- oder 1.26.x-Linie

CVE-2026-58443 — Token-Bypass bei privaten Repos (CVSS 9.6)

Ein API-Token, der ausschließlich mit Public-Scope ausgestellt wurde, kann trotzdem Commits in private Repositories pushen. Die Zugriffskontrolle greift in diesem Fall nicht. Ein kompromittierter öffentlicher Token reicht damit für vollständigen Schreibzugriff auf private Codebases.

Betroffen: Versionen vor 1.27.0
Fix: Gitea 1.27.0

CVE-2026-20896 — Docker Auth-Bypass via HTTP-Header (CVSS 9.8)

Das offizielle Gitea Docker-Image lieferte REVERSE_PROXY_TRUSTED_PROXIES = * als Standard aus. Jeder Angreifer konnte damit via X-WEBAUTH-USER: admin-Header den Adminzugang übernehmen — vollständig ohne Passwort. Die Lücke wurde aktiv ausgenutzt (erste in-the-wild-Scans 13 Tage nach Advisory-Veröffentlichung).

Voraussetzung

CVE-2026-20896 betrifft ausschließlich Docker-Deployments mit aktivierter Reverse-Proxy-Authentifizierung (ENABLE_REVERSE_PROXY_AUTHENTICATION = true). Binary-Installationen ohne diese Konfiguration sind nicht betroffen.

Betroffen: Gitea Docker-Images bis 1.26.2
Fix: Gitea 1.26.3 (Reverse-Proxy-Auth jetzt explizit opt-in)

In Gitea 1.25.5 gepatchte Lücken

Wer direkt von 1.25.4 auf 1.27.1 upgradet, schließt auch alle Fixes aus dem März-Release 1.25.5 mit ein:

CVE-2026-25779 — Redirect-Bypass über Backslash-codierte Pfade
CVE-2026-27660 — Fehlende Berechtigungsprüfung beim Erstellen von Release-Drafts
CVE-2026-27657 — Nutzer konnte die primäre E-Mail-Adresse anderer Accounts ändern
CVE-2026-26232 — OAuth2 Authorization Codes hatten keine korrekte Ablaufzeit- und Wiederverwendungsprüfung
CVE-2026-24690 — Unzureichende Berechtigungsprüfung beim Rebase von Pull-Request-Branches

Sofortmaßnahme (vor dem Upgrade)

Wer nicht sofort upgraden kann: Die Registrierung deaktivieren entzieht Angreifern ohne vorhandenen Account den primären Angriffsvektor für CVE-2026-60004.

# /etc/gitea/app.ini — [service]-Sektion
DISABLE_REGISTRATION = true

# Gitea-Service neu laden
systemctl reload gitea

Kein vollständiger Fix

Das Deaktivieren der Registrierung verhindert nur den unauthentifizierten Angriffsweg. Jeder bestehende Nutzer mit Repository-Write-Zugriff kann CVE-2026-60004 weiterhin ausnutzen. Das Upgrade auf 1.27.1 bleibt zwingend erforderlich.

Upgrade auf Gitea 1.27.1

Das folgende Vorgehen gilt für eine Binary-Installation unter Linux mit systemd-Service. Die gesamte Ausfallzeit beträgt etwa fünf Minuten.

1. Backup

# Service stoppen
systemctl stop gitea

# SQLite-Datenbank sichern
cp /var/lib/gitea/data/gitea.db \
  /var/lib/gitea/data/gitea.db.bak-$(date +%Y%m%d)

# Binary sichern
cp /usr/local/bin/gitea /usr/local/bin/gitea.bak-1.25.4

# Konfiguration sichern
cp /etc/gitea/app.ini /etc/gitea/app.ini.bak-$(date +%Y%m%d)

2. Binary herunterladen und verifizieren

wget -O /tmp/gitea-1.27.1-linux-amd64 \
  https://dl.gitea.com/gitea/1.27.1/gitea-1.27.1-linux-amd64

wget -O /tmp/gitea-1.27.1-linux-amd64.sha256 \
  https://dl.gitea.com/gitea/1.27.1/gitea-1.27.1-linux-amd64.sha256

# Checksum prüfen — muss "OK" ausgeben
cd /tmp && sha256sum -c gitea-1.27.1-linux-amd64.sha256

3. Installieren und DB-Migration ausführen

chmod +x /tmp/gitea-1.27.1-linux-amd64
mv /tmp/gitea-1.27.1-linux-amd64 /usr/local/bin/gitea

# DB-Migration vor Service-Start — wichtig!
/usr/local/bin/gitea migrate --config /etc/gitea/app.ini

systemctl start gitea

Reihenfolge beachten

gitea migrate muss vor dem Service-Start laufen. Andersherum kann Gitea beim Start auf fehlende Datenbankspalten treffen und abstürzen.

4. Verifizieren

# Version prüfen
/usr/local/bin/gitea --version
# → Gitea version 1.27.1 ...

# Service-Status
systemctl status gitea --no-pager

Rollback

Sollte etwas schief gehen: Service stoppen, Backup-Binary (/usr/local/bin/gitea.bak-1.25.4) zurückkopieren, Datenbank-Backup einspielen, Service starten. SQLite macht das trivial.