Ein Header genügt: Wie Gitea und Forgejo jedem Fremden die Admin-Rechte schenkten

CVE-2026-20896 hat einen CVSS-Wert von 9.8 von möglichen 10, und für die vollständige Übernahme eines Servers reicht ein einziger gefälschter HTTP-Header. Kein Passwort. Kein Sitzungstoken. Kein Zwei-Faktor-Code. Nur eine Behauptung, der der Server ungeprüft glaubt. Betroffen sind die offiziellen Docker-Images von Gitea, und weil Forgejo aus demselben Code-Fundament entstanden ist, in derselben Konfiguration auch Forgejo-Server.

Was ein HTTP-Header mit deinem Admin-Zugang zu tun hat

Gitea ist die Software, mit der du deinen eigenen Code hosten kannst, ohne dafür GitHub oder Microsoft zu brauchen. Forgejo ist die Abspaltung davon, entstanden, nachdem Teile der Gitea-Community mit der Unternehmensausrichtung des ursprünglichen Projekts nicht mehr einverstanden waren. Codeberg, der Anbieter, bei dem auch dieser Blog seinen Code liegen hat, setzt Forgejo ein. Viele Vereine und kleine Unternehmen, die ich berate, hosten ihre eigene Gitea- oder Forgejo-Instanz aus genau demselben Grund: raus aus der Abhängigkeit von einem US-Konzern, rein in die eigene Kontrolle.

Beide Programme laufen in der Praxis fast immer hinter einem sogenannten Reverse Proxy: einem vorgeschalteten Server, der eingehende Verbindungen entgegennimmt, meist die Verschlüsselung übernimmt und die Anfrage erst danach an die eigentliche Anwendung weiterreicht. Wenn sich Mitarbeiter*innen bereits über ein zentrales Anmeldesystem ausgewiesen haben, bevor sie überhaupt bei Gitea ankommen, gibt es dafür eine Abkürzung: die Reverse-Proxy-Authentifizierung. Dabei teilt der vorgeschaltete Server Gitea per HTTP-Header mit, wer da gerade anklopft, üblicherweise im Feld X-WEBAUTH-USER. Gitea vertraut dieser Angabe blind und loggt die Person ein, ganz ohne eigene Passwortabfrage. Praktisch, solange wirklich nur der eigene Reverse Proxy diesen Header setzen kann.

Und genau daran hakte es. In den offiziellen Docker-Images von Gitea stand die Einstellung REVERSE_PROXY_TRUSTED_PROXIES standardmäßig auf einem Sternchen als Wildcard. Übersetzt heißt das: Gitea vertraute dem X-WEBAUTH-USER-Header aus jeder beliebigen Quelle, nicht nur vom eigenen Reverse Proxy. Wer die Reverse-Proxy-Authentifizierung aktiviert hatte, öffnete damit ungewollt eine Seitentür für jede beliebige IP-Adresse im Netz. Jede Person, die eine Anfrage direkt an den Gitea-Port schicken konnte, durfte im Header behaupten, sie sei „admin“, und Gitea nahm das für bare Münze.

Warum ausgerechnet dieser Fehler so gefährlich ist

Der CVSS-Wert von 9.8 ergibt sich aus mehreren Faktoren, und bei dieser Lücke schlagen fast alle davon voll aus. Der Angriff funktioniert übers Netz, ohne vorherige Anmeldung, ohne dass irgendjemand draufklicken oder etwas bestätigen muss. Am Ende steht der vollständige Zugriff auf Vertraulichkeit, Integrität und Verfügbarkeit der Instanz: Quellcode lesen, Quellcode verändern, Repositories löschen, neue Administrator*innen-Konten anlegen, sich in aller Ruhe im System einnisten.

Für ein Code-Repository ist das eine der teuersten Kombinationen überhaupt. Wer als Verein oder kleines Unternehmen den eigenen Quellcode selbst hostet, tut das oft, um nicht auf einen US-Konzern und dessen Cloud Act angewiesen zu sein. Eine offene Seitentür im eigenen Keller bringt dann eine neue Sorge mit sich, die vorher jemand anderes getragen hat: die eigene Konfiguration.

Die Zeitleiste eines Fehlers, der lange leise blieb

Der Sicherheitsforscher Ali Mustafa, bekannt unter dem Kürzel rz1027, entdeckte die Lücke und meldete sie verantwortungsvoll. Gitea veröffentlichte am 20. Juni 2026 die offizielle Sicherheitsmitteilung GHSA-f75j-4cw6-rmx4 zusammen mit Version 1.26.3, die den Fehler schließen sollte. Der Patch selbst brachte eine Regression mit, weshalb Gitea bereits einen Tag später, am 21. Juni, Version 1.26.4 nachschob und seither ausdrücklich empfiehlt, direkt auf diese Version zu aktualisieren. Im selben Release bündelte Gitea acht weitere Sicherheitskorrekturen, von serverseitigen Anfragefälschungen in Webhooks bis zu Schwächen bei den Zugriffsrechten auf Branches.

Zwischen der Veröffentlichung eines Patches und dem Moment, in dem draußen im Internet tatsächlich danach gesucht wird, liegt bei kritischen Lücken oft nur wenig Zeit. Der Sicherheitsdienstleister Sysdig beobachtete nach eigenen Angaben ab dem 3. oder 4. Juli 2026, rund 13 Tage nach der Veröffentlichung des Advisorys, automatisiertes Scannen und erste Ausnutzungsversuche gegen erreichbare Gitea-Instanzen. Sysdig-Forscher Michael Clark bezifferte gegenüber BleepingComputer die Zahl der aus dem offenen Internet erreichbaren Gitea-Server auf etwa 6.200. Wie viele davon tatsächlich noch die verwundbare Konfiguration fahren, ist unklar, aber die Richtung der Aktivität ist eindeutig: Es wird systematisch geklopft.

Zur Einordnung, weil hier gern übertrieben wird: Bislang handelt es sich um Scannen und Ausnutzungsversuche, nicht um öffentlich bestätigte, erfolgreiche Kompromittierungen konkreter Instanzen. Wer jetzt liest, ein Gitea-Server stehe „unter Beschuss“, liest eine zugespitzte Überschrift, keine belegte Tatsache. Handeln solltest du trotzdem, aber bei der Wortwahl bleibe ich lieber ehrlich als reißerisch.

Gitea ist gepatcht, Forgejo hängt noch in der Luft

Hier wird es unangenehm für alle, die bewusst von GitHub zu Forgejo gewechselt sind, um genau solchen Risiken zu entgehen. Der Fix für Forgejo liegt längst vor, als Codeberg-Pull-Request forgejo/forgejo #12782, bereits am 28. Mai 2026 gemergt. Nur wurde er bislang in keine veröffentlichte Forgejo-Version zurückportiert. Die aktuellen Sicherheitsmitteilungen der unterstützten Versionslinien, Nummer 53, 54 und 55, erwähnen diesen Fix an keiner Stelle. Stattdessen ist er für Version 16.0.0 vorgesehen und soll dort als Breaking Change in den Release Notes stehen, weil er den gefährlichen Docker-Standardwert endlich ändert.

Version 16.0.0 gibt es zum Zeitpunkt dieses Artikels schlicht noch nicht. Die aktuellen Forgejo-Releases sind 15.0.4 und 11.0.16, beide vom 9. Juli 2026, beide ohne diesen Fix. Wer einen Forgejo-Server mit aktivierter Reverse-Proxy-Authentifizierung betreibt, sitzt Stand heute mit derselben offenen Seitentür da wie Gitea-Nutzer*innen vor dem 20. Juni, nur ohne die Möglichkeit, sie mit einem einfachen Update zuzuschlagen.

Ob Codeberg selbst, das dieselbe Software für den eigenen Betrieb einsetzt, jemals verwundbar war, lässt sich aus öffentlich verfügbaren Quellen nicht beantworten. Weder auf dem Codeberg-Blog noch auf der Statusseite noch in der Fachpresse findet sich eine Stellungnahme dazu, ob die Reverse-Proxy-Authentifizierung dort aktiv war oder ist. Diese Frage bleibt an dieser Stelle ausdrücklich offen. Es wäre unseriös, sie in die eine oder andere Richtung zu beantworten, ohne dass es dafür eine Quelle gibt.

Eine Verwechslung lohnt sich noch zu klären: Parallel zu dieser Lücke kursiert CVE-2026-27771, ein Bypass in der Container-Registry-Funktion mit einem CVSS-Wert von 8.2, geschätzt über 30.000 betroffene Instanzen, aber bereits rund vier Jahre alt und schon mit Version 1.26.2 geschlossen. Das bleibt ein eigenständiges, deutlich älteres Problem, unabhängig von der hier beschriebenen Lücke.

Was du jetzt tun musst, wenn du Gitea betreibst

Betreibst du eine eigene Gitea-Instanz über Docker, ist der erste Schritt simpel: Aktualisiere auf Version 1.26.4. Nicht auf 1.26.3, sondern direkt auf 1.26.4, weil die Zwischenversion selbst noch eine Regression enthielt, die Gitea inzwischen mitbehoben hat. Danach lohnt sich ein zweiter Blick in die eigene app.ini-Konfigurationsdatei: Steht dort ENABLE_REVERSE_PROXY_AUTHENTICATION auf true, prüfe direkt daneben den Wert von REVERSE_PROXY_TRUSTED_PROXIES. Ein Sternchen an dieser Stelle bedeutet, du vertraust jeder beliebigen Quelle, das gehört durch die tatsächliche, feste IP-Adresse deines Reverse Proxys ersetzt, nicht durch einen Platzhalter.

Zusätzlich gilt eine Grundregel, die unabhängig von dieser konkreten Lücke immer gilt: Der Anwendungsport von Gitea sollte nie direkt aus dem Internet erreichbar sein. Läuft dein Setup in Docker, gehört der Gitea-Container in ein internes Docker-Netzwerk, aus dem nur der Reverse Proxy herausreicht. Wer die Reverse-Proxy-Authentifizierung ohnehin nicht wirklich braucht, etwa weil jede Person sich ganz normal mit Benutzername und Passwort bei Gitea selbst anmeldet, schaltet die Funktion am besten komplett ab. Eine Tür, die niemand einbaut, kann niemand aufbrechen.

Was du jetzt tun musst, wenn du Forgejo betreibst

Weil der offizielle Fix bei Forgejo auf sich warten lässt, bist du hier stärker auf dich selbst gestellt. Prüfe genauso wie bei Gitea, ob ENABLE_REVERSE_PROXY_AUTHENTICATION bei dir aktiv ist. Falls ja, setze REVERSE_PROXY_TRUSTED_PROXIES sofort manuell auf die konkrete IP-Adresse deines Reverse Proxys, warte nicht auf Version 16. Kontrolliere parallel, ob dein Forgejo-Port wirklich nur intern erreichbar ist und nicht versehentlich über eine offene Portfreigabe direkt aus dem Internet erreichbar ist.

Und behalte die Forgejo-Release-Seite im Blick. Sobald Version 16.0.0 erscheint, ändert sich der Docker-Standardwert endlich von selbst. Bis dahin bleibt die manuelle Korrektur deine einzige verlässliche Absicherung.

Selbstgehostet heißt nicht erledigt

Diese Lücke ist unbequem für alle, die den Wechsel weg von GitHub und Microsoft als abgeschlossenes Kapitel betrachten. Er ist es nicht. Wer den eigenen Code selbst hostet, hat sich damit bewusst gegen die Abhängigkeit von einem US-Konzern entschieden, und das war die richtige Entscheidung. Mit dieser Entscheidung übernimmt man aber auch die Verantwortung, die vorher irgendwo in Redmond oder San Francisco lag: Patches einspielen, Konfigurationswerte prüfen, Standardeinstellungen hinterfragen, statt sie einfach zu übernehmen, nur weil sie schon so voreingestellt waren.

Genau an dieser Stelle hört digitale Unabhängigkeit häufig zu früh auf. Der Server steht, die Migration ist geschafft, das Häkchen ist gesetzt, und dann vergisst man, dass ein selbst gehosteter Dienst genauso viel laufende Pflege braucht wie eine Wohnung, die man gekauft hat, statt sie zu mieten. Niemand kümmert sich mehr automatisch um das Dach. Das bist ab jetzt du.

Wenn dir das nach mehr klingt, als du allein im Blick behalten willst, oder wenn du gerade erst überlegst, den Schritt zu Gitea oder Forgejo überhaupt zu gehen, und von Anfang an wissen willst, wie man das sicher aufsetzt: Genau dafür berate ich Vereine und Unternehmen bei Server-Infrastruktur und Selbsthosting.

Reden wir über deine Serverabsicherung.

Schreib mir eine E-Mail: Kurz beschreiben, was du vorhast oder was dich beschäftigt. Ich melde mich in der Regel innerhalb eines Werktages. hallo@chrislo.de

Kein Kontaktformular, keine Pflichtfelder, keine Datenspur. Einfach schreiben.