Kritische Gitea-Docker-Sicherheitslücke CVE-2026-20896 im Detail

In den Docker-Images der Plattform Gitea wurde die kritische Sicherheitslücke CVE-2026-20896 mit einem CVSS-Score von 9.8 entdeckt. Sie ermöglicht es einem nicht authentifizierten Angreifer, auf beliebige Benutzerkonten zuzugreifen – einschließlich administrativer Konten – und zwar ohne Passwort und Token. Die Schwachstelle betrifft alle Versionen der Gitea-Docker-Images bis einschließlich 1.26.2 und wurde in Version 1.26.3 behoben. Nach Angaben des Unternehmens Sysdig wurde bereits 13 Tage nach der öffentlichen Offenlegung eine Aktivität beobachtet, die auf die Aufklärung verwundbarer Instanzen hindeutet, auch wenn bislang keine bestätigten Fälle erfolgreicher Ausnutzung bekannt sind. Administratoren von Gitea, die ein Docker-Deployment mit Reverse Proxy einsetzen, müssen umgehend ein Update durchführen.

Technischer Kern der Sicherheitslücke

Die Ursache des Problems liegt in der Konfigurationsdatei app.ini, die als zentrale Konfigurationsdatei von Gitea fungiert und Serverparameter, Datenbankverbindungen sowie Sicherheitsverhalten steuert. In den Docker-Images von Gitea setzte diese Vorlage den Parameter REVERSE_PROXY_TRUSTED_PROXIES = * hartkodiert, was bedeutete, dass dem HTTP-Header X-WEBAUTH-USER von jeder Quell-IP-Adresse vertraut wurde.

Der dokumentierte, sichere Standardwert für diesen Parameter lautet 127.0.0.0/8,::1/128, das heißt, es wird nur localhost vertraut. Das Docker-Image ignorierte diesen Standardwert jedoch und ersetzte ihn durch das Platzhalterzeichen *. De facto wurde damit die Prüfung der vertrauenswürdigen Proxies ausgehebelt.

Der Ausnutzungsmechanismus stellt sich wie folgt dar:

1. Die Administration aktiviert den Parameter ENABLE_REVERSE_PROXY_AUTHENTICATION = true, um Gitea hinter einem authentifizierenden Reverse Proxy zu betreiben
2. Der Parameter REVERSE_PROXY_TRUSTED_PROXIES bleibt auf dem Standardwert (*)
3. Jeder Prozess, der den HTTP-Port des Gitea-Containers direkt erreichen kann – also unter Umgehung des vorgesehenen authentifizierenden Proxies – kann einen beliebigen X-WEBAUTH-USER-Header senden
4. Der Server akzeptiert den Headerwert ohne weitere Prüfung als Namen des authentifizierten Benutzers

Wie im offiziellen Gitea-Sicherheitsbulletin beschrieben, geraten damit naheliegende administrative Konten mit vorhersehbaren Namen ins Visier, etwa admin, gitea_admin und ähnliche. Ist die automatische Registrierung von Benutzern aktiviert, kann ein Angreifer ein Konto mit einem Administratornamen anlegen und sich so volle Privilegien verschaffen.

Die Schwachstelle wurde von dem Sicherheitsforscher Ali Mustafa (Али Мустафа) entdeckt und offengelegt. Das öffentliche Repository des Forschers enthält Details zur Offenlegung, was darauf hinweist, dass ausreichende technische Informationen zur Reproduktion des Angriffs frei verfügbar sind.

Betroffene Versionen und Behebung

• Verwundbare Versionen: Gitea-Docker-Images bis einschließlich Version 1.26.2
• Bereinigte Version: 1.26.3 (das Platzhalterzeichen * wurde entfernt, die Authentifizierung über den Reverse Proxy auf explizite Aktivierung umgestellt)

Wichtig ist zu betonen: Die Schwachstelle ist spezifisch für die Docker-Images von Gitea. Eine Standardinstallation aus Binärdateien verwendet den sicheren Standardwert. Das Problem entstand durch eine Diskrepanz zwischen dem dokumentierten Verhalten und der tatsächlich im Container-Image ausgelieferten Konfiguration.

Beobachtete Aktivität

Nach Angaben von Sysdig wurde die erste mit dieser Schwachstelle in Verbindung stehende Aktivität 13 Tage nach der öffentlichen Offenlegung registriert. Es ist jedoch zu berücksichtigen, dass diese Information auf einer einzelnen Quelle basiert und den Charakter operativer Telemetrie hat.

Michael Clark, Senior Director of Threat Research bei Sysdig, beschrieb die beobachtete Aktivität als erste Aufklärung, die noch nicht in eine Phase tatsächlicher Ausnutzung übergegangen sei. Es wurde die IP-Adresse 159.26.98[.]241 erfasst, die zum Dienst ProtonVPN gehört. Die Nutzung eines VPN-Dienstes erlaubt keine Rückschlüsse auf die Attribution – es kann sich sowohl um gezielte Aufklärung als auch um automatisiertes Scanning handeln.

Der Ausnutzungsstatus ist daher als Scanning und nicht als bestätigte Ausnutzung unter Realbedingungen einzuordnen. Schätzungen zufolge sind im Internet rund 6.200 Gitea-Instanzen erreichbar, wobei diese Zahl nicht durch unabhängige Messungen verifiziert ist.

Bewertung der Auswirkungen

Die Kritikalität der Schwachstelle ergibt sich aus mehreren Faktoren. Gitea wird von Entwicklungsteams weit verbreitet als selbst gehostete Alternative zu GitHub und GitLab eingesetzt. Die Kompromittierung eines administrativen Zugangs zu Gitea eröffnet den Weg zur Manipulation von Quellcode, zum Einschleusen bösartiger Commits in die Software-Lieferkette, zum Diebstahl von Secrets und Tokens aus Repositories sowie zu lateralen Bewegungen innerhalb der Infrastruktur einer Organisation.

Die niedrige Einstiegsschwelle für die Ausnutzung – es genügt das Senden eines einzigen HTTP-Headers – in Kombination mit einem CVSS-Score von 9.8 und öffentlich verfügbaren technischen Details macht diese Schwachstelle zu einer vorrangig zu beseitigenden Gefahr.

Empfehlungen

• Sofortiges Update: Aktualisieren Sie das Gitea-Docker-Image auf Version 1.26.3 oder höher
• Konfigurationsprüfung: Stellen Sie sicher, dass in der Datei app.ini der Parameter REVERSE_PROXY_TRUSTED_PROXIES auf 127.0.0.0/8,::1/128 und nicht auf * gesetzt ist
• Audit des Netzwerkzugriffs: Stellen Sie sicher, dass der HTTP-Port des Gitea-Containers nicht direkt aus dem Internet erreichbar ist und nur Verbindungen von einem vertrauenswürdigen Reverse Proxy akzeptiert
• Log-Analyse: Untersuchen Sie die Protokolle auf Anfragen mit dem Header X-WEBAUTH-USER von IP-Adressen, die nicht zu Ihrem Reverse Proxy gehören
• Audit der Benutzerkonten: Überprüfen Sie, ob verdächtige Konten existieren, insbesondere mit administrativen Rechten, die im Zeitraum der Verwundbarkeit angelegt wurden

Organisationen, die ein Docker-Deployment von Gitea mit Authentifizierung über einen Reverse Proxy betreiben, müssen das Image auf Version 1.26.3 aktualisieren und den Wert von REVERSE_PROXY_TRUSTED_PROXIES in der Konfiguration prüfen. Angesichts der verfügbaren technischen Details, der CVSS-Bewertung von 9.8 und der beobachteten Scans wird das Zeitfenster für ein sicheres Update enger – die Priorität für die Behebung sollte maximal sein.