Sicherheit · Selbsthosting · Docker
Gitea Docker Authentifizierungsumgehung (CVE-2026-20896): Bist du betroffen und wie behebst du es
Wenn du Gitea aus seinem offiziellen Docker-Image selbst hostest, erfordert ein kritischer Fehler jetzt deine Aufmerksamkeit. CVE-2026-20896 ist eine Authentifizierungsumgehung mit der Bewertung CVSS 9.8, und laut Berichten von BleepingComputer, The Hacker News und SecurityWeek wird sie bereits aktiv in freier Wildbahn ausgenutzt. Die gute Nachricht: Ob du betroffen bist, lasst sich leicht prufen, und die Behebung ist ein schnelles Upgrade plus eine Einstellung.
Was die Schwachstelle tatsachlich ist
Das Problem ist eine unsichere Standardeinstellung im Container, nicht in der Kernlogik von Gitea. Das offizielle Docker-Image von Gitea wird mit REVERSE_PROXY_TRUSTED_PROXIES=* ausgeliefert, was bedeutet, dass Gitea dem Reverse-Proxy-Authentifizierungsheader X-WEBAUTH-USER von jeder Quell-IP-Adresse vertraut. Wenn die Reverse-Proxy-Authentifizierung aktiviert ist, sollte dieser Header nur von einem vertrauenswurdigen Proxy stammen, der den Benutzer bereits angemeldet hat. Mit einem Platzhalter kann ein nicht authentifizierter Client im Internet den Header einfach selbst senden und zu dem werden, was er vorgibt zu sein. Das ist die gesamte Umgehung.
Wer tatsachlich betroffen ist
Nicht jede Gitea-Installation ist gefahrdet. Basierend auf den veroffentlichten Hinweisen bist du betroffen, wenn all dies zutrifft: Du betreibst das offizielle Docker-Image von Gitea in Version 1.26.2 oder fruher, du hast Reverse-Proxy-Authentifizierungsheader aktiviert, und die Instanz ist aus dem offentlichen Internet erreichbar. Installationen, die keine Reverse-Proxy-Header-Authentifizierung verwenden oder nur in einem privaten Netzwerk erreichbar sind, sind uber diesen spezifischen Weg nicht ausnutzbar, auch wenn ein Upgrade trotzdem der richtige Schritt ist.
Warum es wichtig ist
Ein Git-Server ist ein hochwertiges Ziel. Forscher beschreiben Angreifer, die nach dem Passieren der Authentifizierung private Repositories lesen, Geheimnisse und Quellcode exfiltrieren, Benutzerkonten erstellen oder andern und moglicherweise bosartige Anderungen in CI/CD-Pipelines einschleusen konnen, die aus diesen Repositories laufen. Sysdig berichtete, den ersten Treffer in freier Wildbahn innerhalb weniger Tage nach Bekanntwerden der Technik erfasst zu haben, von automatisierten Scannern, die VPN-Exit-Knoten nutzen. Mit anderen Worten: Exponierte Instanzen werden automatisch gefunden und getroffen.
Wie du es prufst und behebst
- Zuerst aktualisieren. Gitea hat 1.26.3 und 1.26.4 veroffentlicht, die das Problem beheben. Ziehe das gepatchte Image und stelle es erneut bereit.
- Behebe die Einstellung fur vertrauenswurdige Proxys. Belasse
REVERSE_PROXY_TRUSTED_PROXIESnicht auf*. Setze es auf die tatsachliche IP oder das Subnetz deines Reverse-Proxys, damit Gitea dem Authentifizierungsheader nur von dieser Quelle vertraut. - Reduziere die Exposition. Wenn ein Git-Server nicht im offentlichen Internet sein muss, stelle ihn hinter ein VPN oder eine Firewall. Weniger exponierte Dinge bedeuten weniger gescannte Dinge.
- Prufe auf Missbrauch. Uberprufe nach dem Patchen deine Gitea-Benutzerliste und Protokolle auf unerwartete Konten oder Zugriffe, da die Ausnutzung deiner Behebung vorausgehen konnte.
Die umfassendere Lektion
Dies ist ein klassisches Versagen einer "unsicheren Standardeinstellung": Die Software war in Ordnung, aber der Container wurde mit einer freizugigen Einstellung ausgeliefert, die gefahrlich wird, sobald der Dienst dem Internet ausgesetzt ist. Selbsthosting lohnt sich, aber es geht mit der Verantwortung einher, die Standardeinstellungen der Images zu uberprufen, die du betreibst, besonders alles, was Authentifizierungsheader von einem Proxy akzeptiert. Eine Platzhalter-Vertrauenseinstellung ist genau die Art von Standardeinstellung, die es sich lohnt zu prufen, bevor du einen Dienst exponierst.
FAQ
Was ist CVE-2026-20896? Eine kritische (CVSS 9.8) Authentifizierungsumgehung im offiziellen Docker-Image von Gitea in Version 1.26.2 und fruher, verursacht durch das Vertrauen in den X-WEBAUTH-USER-Header von jeder IP. Sie wird aktiv ausgenutzt.
Bin ich betroffen, wenn ich keine Reverse-Proxy-Authentifizierung verwende? Uber diesen spezifischen Weg nein. Die Umgehung hangt davon ab, dass Reverse-Proxy-Authentifizierungsheader aktiviert sind. Ein Upgrade wird trotzdem empfohlen.
Wie behebe ich es? Aktualisiere auf Gitea 1.26.3 oder 1.26.4 und setze REVERSE_PROXY_TRUSTED_PROXIES auf die echte IP deines Proxys statt auf einen Platzhalter.
Konnte ich bereits kompromittiert worden sein? Moglicherweise, wenn du vor dem Patchen exponiert warst. Uberprufe Benutzerkonten und Zugriffsprotokolle auf alles Unerwartete.