Fehler 9.8 in Gitea Docker wird aktives Ziel: Ein einziger Header gewährt Admin-Zugang zu Repositories

Sysdig hat in einem diese Woche von The Hacker News veröffentlichten Bericht bestätigt, dass die CVE-2026-20896 in Gitea Docker nicht mehr nur eine Hypothese ist, sondern zu einem aktiven Ziel im Internet geworden ist. Der erste Versuch einer Ausnutzung in Produktion kam 13 Tage nach der Veröffentlichung des Fehlers und kam von einem Ausgangsknoten von ProtonVPN unter 159.26.98.241, mit einem typischen Scan-Muster einer breiten Kampagne: Scannen nach exponierten Diensten, Versuch des Bypass, Antwortensammlung.

Der Fehler ist grob in dem, was er ermöglicht. Der CVSS-Wert liegt bei 9.8, da das offizielle Docker-Image mit einer Vorlage app.ini bereitgestellt wurde, die REVERSE_PROXY_TRUSTED_PROXIES = * festlegte. In Kombination mit der Header-Authentifizierung akzeptierte der Server den Header X-WEBAUTH-USER von jeder IP und behandelte ihn als bestätigte Identität. Mit anderen Worten: Ein nicht authentifizierter Client aus dem offenen Internet kann sich als jeder Benutzer von Gitea, einschließlich Administrator, ausgeben, ohne Passwort, SSH-Schlüssel oder Token zu verwenden.

Was ist exponiert

Sysdig zählt derzeit etwa 6.200 Gitea-Instanzen, die im Internet exponiert sind, zu dem Zeitpunkt, als die Ausnutzung begann, sichtbar zu werden. Nicht alle diese Basis nutzt das verwundbare Docker-Image, aber die betroffene Untergruppe umfasst genau das Profil, das für kriminelle Betreiber am interessantesten ist: interne Entwicklungsteams mittelgroßer Unternehmen, Code-Server von Startups, Unternehmenslabore, die sich für die Selbsthosting-Option entschieden haben, anstatt GitHub oder GitLab zu verwenden, sowie verwaltete Anbieter, die Gitea in Containern zum Wiederverkauf gepackt haben.

Der Inhalt dieser Repositories ist oft mehr wert als der Code selbst. CI/CD-private Schlüssel, Cloud-Token, Datenbank-Anmeldeinformationen in Konfigurationsdateien, Infrastruktur-Definitionen als Code mit internen Endpunkten, Daten-Notebooks und Commit-Historien mit zurückgerollten und nie bereinigten Geheimnissen erscheinen in den meisten selbstgehosteten Umgebungen, die keiner formalen Prüfung unterzogen wurden. Ein Admin-Zugang zu Gitea ermöglicht die Einsicht in alle privaten Repos der Organisation, ohne ein normales Authentifizierungsprotokoll zu erzeugen, da der Server tatsächlich glaubt, dass die Anfrage legitim ist.

Wie es zu diesem Zustand gekommen ist

Die Verwundbarkeit wurde von den Betreuern von Gitea zusammen mit dem Release 1.26.3 veröffentlicht, mit der Aufforderung an die Administratoren, umgehend zu aktualisieren oder die Zeile REVERSE_PROXY_TRUSTED_PROXIES = * aus der Datei app.ini zu entfernen. Laut Sysdig folgt das Zeitfenster von 13 Tagen zwischen Veröffentlichung und dem ersten beobachteten Versuch der Ausnutzung dem Durchschnitt, den das Unternehmen in N-day-Kampagnen misst: öffentliche Bots konsumieren den CVE-Feed, generieren Scan-Signaturen und initiieren massenhaft Scans, oft bevor interne Teams den Inventar aus betroffenen Instanzen abgeschlossen haben.

Die Tatsache, dass die Ausnutzung von einem ProtonVPN-Knoten ausging, weist nicht auf eine spezifische Autorenschaft hin. Es ist gängige Praxis in opportunistischen Aufklärungskampagnen, und Sysdig hat festgestellt, dass bis zu dem Zeitpunkt des Berichts keine bestätigten Berichte über erfolgreiche Nachausnutzung oder Lecks, die direkt auf den Fehler zurückzuführen sind, vorliegen. Das ist jedoch kein Trost: Der Zeitraum zwischen Scan und Nutzung wird oft in Stunden gemessen, wenn der Exploit wie in diesem Fall funktioniert, ohne dass ein anspruchsvoller Payload erforderlich ist.

Was jetzt zu tun ist

Für Betreiber von Gitea Docker ist das Playbook kurz und dringend. Aktualisieren Sie auf 1.26.3, entfernen oder beschränken Sie REVERSE_PROXY_TRUSTED_PROXIES auf tatsächlich vertrauenswürdige Bereiche, überprüfen Sie die Zugriffsprotokolle der letzten zwei Wochen auf Anfragen mit unerwartetem X-WEBAUTH-USER und zwingen Sie die Rotation von Anmeldeinformationen, die im Klartext innerhalb privater Repos erscheinen. Teams, die Gitea über öffentlichen Ingress ohne WAF davor exponieren, sollten die Instanz als kompromittiert betrachten, bis das Gegenteil bewiesen ist, insbesondere wenn die Version seit mehr als ein paar Tagen hinter 1.26.3 zurückliegt.

Der Fall zeigt ein sich wiederholendes Muster in DevOps-Produkten: Eine Standardkonfiguration, die für einfache interne Deployments gedacht ist, wird zur offenen Tür, wenn dasselbe Image in einer öffentlichen Umgebung hochgeladen wird. REVERSE_PROXY_TRUSTED_PROXIES = * ist sinnvoll in einer Umgebung, in der nur ein bekannter Reverse-Proxy mit dem Container kommuniziert. Dieses Wert als Standard in einem offiziellen Image, das für Szenarien verteilt wird, die niemand vorhersagen kann, zu belassen, ist die Art von Ingenieurauswahl, die oft zu einer kritischen CVE führt. Die schnelle Reaktion des Gitea-Teams behebt den Fehler, aber die Lektion für alle, die Containerflotten verwalten, ist, dass die Sicherheitsüberprüfung vor dem Pull und nicht nach dem ersten Alarm erfolgen muss.