Gitea-Docker-Images: CVE-2026-20896 — ein HTTP-Header genügt für Admin-Zugriff, jetzt aktiv gescannt

TL;DR — 90 Sekunden

Betroffen?

Gitea-Instanzen aus dem offiziellen Docker-Image (docker/root und docker/rootless), Version 1.26.2 und früher, mit ENABLE_REVERSE_PROXY_AUTHENTICATION = true. Binärinstallationen nach app.example.ini sind nicht betroffen.

Risiko?

Unauthentifizierte Rechteausweitung zum Admin durch Spoofing des X-WEBAUTH-USER-Headers. CVSS 3.1 9.8 (kritisch) — Netzwerk, keine Auth, keine Interaktion nötig.

Sofortmaßnahme?

Auf Gitea 1.26.4 aktualisieren (1.26.3 wird in Presseberichten eine Regression nachgesagt — direkt auf 1.26.4 zielen) oder, falls ein Update nicht sofort möglich ist, REVERSE_PROXY_TRUSTED_PROXIES händisch auf 127.0.0.0/8,::1/128 setzen.

Empfehlung?

Heute patchen, nicht diese Woche: Seit 07.07.2026 aktiv gescannt (Sysdig), ~6.200 Instanzen laut Shodan-Abfrage potenziell erreichbar (Gesamtzahl der tatsächlich verwundbaren Instanzen unbestätigt).

Kritikalität?

kritisch (Hero-Badge) — volle unauthentifizierte Admin-Übernahme bei direktem Zugriff auf den Container-Port.

Was ist das Problem?

Gitea unterstützt Reverse-Proxy-Authentifizierung: Ein vorgeschalteter Proxy übernimmt die eigentliche Anmeldung und reicht die verifizierte Identität per HTTP-Header (X-WEBAUTH-USER) an die Anwendung weiter. Damit das sicher funktioniert, muss Gitea diesem Header nur vertrauen, wenn die Anfrage tatsächlich vom Proxy stammt — gesteuert über REVERSE_PROXY_TRUSTED_PROXIES. Der dokumentierte sichere Default ist Loopback-only (127.0.0.0/8,::1/128).

Genau dieser Default ist in den offiziellen Docker-Image-Vorlagen falsch gesetzt: docker/root/etc/templates/app.ini (Zeile 55) und die entsprechende Rootless-Variante (Zeile 52) hardcoden stattdessen REVERSE_PROXY_TRUSTED_PROXIES = * — ein Wildcard, der jede Quelladresse als vertrauenswürdig behandelt. Ist ENABLE_REVERSE_PROXY_AUTHENTICATION aktiviert (in reverse-proxy-basierten Deployments üblich), reicht damit ein selbst gesetzter X-WEBAUTH-USER-Header von jeder Quelle, um sich als der genannte Nutzer auszugeben — Admin-Accounts eingeschlossen. Der Sicherheitsforscher Ali Mustafa, der die Lücke meldete, bringt es auf den Punkt: Jeder Prozess, der den HTTP-Port des Containers direkt erreicht, kann jeden Nutzer imitieren — unabhängig davon, ob die Instanz öffentlich erreichbar ist oder „nur“ intern.

Wichtig für die Einordnung: Binärinstallationen, die der offiziellen app.example.ini folgen, sind von diesem Fund nicht betroffen — das Problem steckt ausschließlich in den Docker-Image-Vorlagen.

Wer ist betroffen?

Laut einer Shodan-Abfrage sind rund 6.200 Gitea-Instanzen grundsätzlich internetseitig erreichbar; wie viele davon tatsächlich das verwundbare Docker-Image und die verwundbare Konfiguration fahren, ist damit nicht belegt — nur die grobe Angriffsfläche.

Auswirkungen

Eine erfolgreiche Ausnutzung bedeutet vollständige Identitätsübernahme, nicht nur Leserechte: Wer sich per Header-Spoofing als Admin ausgibt, hat Zugriff auf sämtliche Repositories inklusive privater Repos, kann CI/CD-Secrets einsehen, die in Repository- oder Organisations-Variablen liegen, kann Commits auf geschützte Branches pushen, CI-Pipelines manipulieren und Nutzerkonten anlegen oder löschen. Gerade weil selbst gehostete Git-Server wie Gitea typischerweise sowohl Quellcode als auch Deployment-Secrets bündeln, ist der Fund ein Multiplikator für nachgelagerte Supply-Chain-Risiken: ein kompromittiertes Gitea ist potenziell der Ausgangspunkt für kompromittierte Downstream-Artefakte.

Die Ausnutzung erfordert keine Authentifizierung und keine Nutzerinteraktion — lediglich Netzwerkzugriff auf den Container-HTTP-Port. Das ist der Kern der CVSS-3.1-Bewertung von 9.8.

Mitigation / Sofortmassnahmen

Hinweis: Die folgenden Schritte sind meine operative Einordnung auf Basis von GHSA-f75j-4cw6-rmx4 und der zitierten Berichterstattung — kein herstellerzertifizierter Leitfaden. Konkrete Versionsstände gegen das Gitea-Advisory abgleichen.

Operativer Entscheidungsblock

• Jetzt handeln, wenn … Sie das offizielle Docker-Image mit ENABLE_REVERSE_PROXY_AUTHENTICATION = true fahren und REVERSE_PROXY_TRUSTED_PROXIES nicht explizit gesetzt haben.
• Mit Priorität prüfen, wenn … Sie nicht sicher sind, ob Ihr Image-Build der verwundbaren Vorlage folgt.
• Nur beobachten, wenn … Sie eine Binärinstallation nach app.example.ini mit korrekt gesetzten Trusted Proxies betreiben.

Schritt 1 — Auf 1.26.4 aktualisieren

# aktuelle Version prüfen
docker exec <gitea-container> gitea --version
# gepatchtes Image ziehen (1.26.4 — 1.26.3 hat laut Presseberichten eine Regression)
docker pull gitea/gitea:1.26.4
docker compose up -d gitea

Schritt 2 — Bis zum Patch: Trusted Proxies händisch einschränken

# in app.ini (Volume-Mount oder docker exec in den Container):
[security]
REVERSE_PROXY_TRUSTED_PROXIES = 127.0.0.0/8,::1/128
# Neustart
docker restart <gitea-container>

Schritt 3 — Netzwerk härten

# Container-HTTP-Port nicht direkt exponieren — nur der Reverse Proxy soll ihn erreichen
# docker-compose.yml prüfen: keine 0.0.0.0-Bindings, die den Port am Proxy vorbeireichen
# in Kubernetes: NetworkPolicy, die den Pod-Port nur für den Ingress/Proxy freigibt

Schritt 4 — Falls nicht benötigt: Reverse-Proxy-Auth abschalten

[service]
ENABLE_REVERSE_PROXY_AUTHENTICATION = false

Detection / Prüfung

Prüfpunkte abgeleitet aus dem Advisory und gängiger Docker-/Log-Praxis.

Version & Konfiguration prüfen

docker exec <gitea-container> gitea --version
docker exec <gitea-container> grep -A3 "\[security\]" /data/gitea/conf/app.ini | grep -i trusted_proxies
docker exec <gitea-container> grep -i enable_reverse_proxy /data/gitea/conf/app.ini

Logs auf Header-Spoofing prüfen

# X-WEBAUTH-USER von Quellen ausserhalb der erwarteten Proxy-IP im Access-Log?
grep -i "x-webauth-user" /pfad/zu/reverse-proxy/access.log | awk '{print $1}' | sort -u

Admin-Liste auf unbekannte Accounts prüfen

curl -s -H "Authorization: token <admin-token>" \
  gitea.example.com/api/v1/admin/users | jq '.[] | select(.is_admin==true) | .login'

Laufzeit-Indikatoren

- neue/unbekannte Admin-Accounts
- unerwartete Commits auf geschützten Branches
- Änderungen an CI/CD-Pipelines ausserhalb bekannter Deploy-Fenster
- X-WEBAUTH-USER-Header in Requests, die nicht vom konfigurierten Proxy stammen

Betreiberempfehlung

Mid-Market

Patchen Sie diese Woche auf 1.26.4 — Gitea-Instanzen bündeln in der Regel Quellcode und CI-Secrets, was den Fund zu einem Hebel für nachgelagerte Vorfälle macht. Prüfen Sie parallel, ob REVERSE_PROXY_TRUSTED_PROXIES je explizit gesetzt wurde; wenn nicht, war Ihre Instanz vermutlich seit der Docker-Image-Erstellung exponiert.

Enterprise

Zusätzlich: Container-Netzwerkexposition auditieren — ist der HTTP-Port über den vorgesehenen Proxy-Hop hinaus erreichbar? Interne Netzsegmentierung zählt hier, weil der Fund keine öffentliche Erreichbarkeit voraussetzt. SBOM-/Inventory-Abgleich, welche internen Systeme direkten Netzwerkzugriff auf Gitea-Container haben.

Kubernetes

NetworkPolicy prüfen, die den Zugriff auf den Gitea-Pod-HTTP-Port auf Ingress/Proxy beschränkt; Service-Typ auditieren (NodePort/LoadBalancer, die den rohen Port exponieren, vermeiden); Image-Pin auf 1.26.4 in Helm-Values/Manifest aktualisieren.

Entscheidungsblock

Heute handeln, wenn: Docker-Image + Reverse-Proxy-Auth aktiv + REVERSE_PROXY_TRUSTED_PROXIES nicht geprüft. Beobachten, wenn: Binärinstallation mit dokumentiertem sicherem Default.

Fazit

CVE-2026-20896 ist ein Lehrbuchbeispiel dafür, wie ein einzelner falscher Default in einer Distributionsvorlage — nicht im Anwendungscode selbst — zur unauthentifizierten Admin-Übernahme wird. Der Fix ist unkompliziert (Update oder eine Zeile Konfiguration), aber die Ausnutzung ist trivial und seit dem 7. Juli 2026 aktiv beobachtet. Wer Gitea aus dem offiziellen Docker-Image betreibt und Reverse-Proxy-Auth nutzt, sollte REVERSE_PROXY_TRUSTED_PROXIES heute prüfen — unabhängig davon, ob die Instanz öffentlich erreichbar ist.

Quellen

• Gitea Security Advisory GHSA-f75j-4cw6-rmx4 (go-gitea/gitea; autoritative Fix-Version 1.26.3)
• The Hacker News — Threat Actors Probe Gitea Docker Flaw CVE-2026-20896 13 Days After Disclosure (06.07.2026)
• Tech Times — Gitea Docker Flaw Now Actively Probed (12.07.2026; Hinweis auf Regression in 1.26.3, Empfehlung 1.26.4)
• Security Affairs — Critical Gitea Docker Bug Under Active Exploitation (07.07.2026; ~6.200 Instanzen laut Shodan)