blog.bubam.de

Notizen zu Technik, Macht und Souveränität — und dem, was darunter läuft.

RSS · kein Tracking · keine Kommentare · Themen-Tipp? blog@bubam.de

Themen: Souveränität · Datensouveränität · Überwachung & Bürgerrechte · KI & Macht · Security · Recht & Regulierung · Heuchelei & Machtmissbrauch · Werkstatt

11. Juli 2026

„Ein Header genügt"

Als hier Ende Juni der Beitrag über den 0-Day-Massendrop stand, gab es eine persönliche Fußnote: Unter den frisch gemeldeten Lücken war eine in Gitea, und weil ich selbst eine Gitea-Instanz betreibe, habe ich noch am selben Abend geprüft und gehärtet. Jetzt liefert die Geschichte ihren zweiten Akt, und der ist ein Lehrstück in Echtzeit.

Die Lücke, CVE-2026-20896, ist von der unangenehmen Sorte: CVSS 9.8, und der Angriff ist beleidigend simpel. Die offiziellen Docker-Images vor Version 1.26.3 nehmen den Header X-WEBAUTH-USER von jeder beliebigen Quell-IP entgegen — ein Mechanismus, der eigentlich für vorgeschaltete Auth-Proxys gedacht ist und dem nur der Proxy schreiben dürfte. Fehlt die Absicherung, genügt ein einziger HTTP-Header, um sich als beliebiger existierender Nutzer auszugeben. Kein Passwort, kein Token, kein Exploit-Kit: ein Header. Dahinter liegt dann alles, wofür man eine Code-Schmiede betreibt — private Repositories, versehentlich committete API-Schlüssel, CI/CD-Konfiguration, Deploy-Keys.

Seit dieser Woche ist das kein theoretisches Risiko mehr: Sysdig hat die ersten Angriffe in freier Wildbahn gemessen, dreizehn Tage nach der Veröffentlichung des Advisories, Ausgangspunkt ein VPN-Exit-Node. Rund 6.200 Gitea-Instanzen sind offen aus dem Internet erreichbar; wie viele davon verwundbar sind, weiß niemand genau — die Angreifer sind gerade dabei, es herauszufinden. Dreizehn Tage von der Disclosure zum Angriff ist übrigens die eigentliche Zahl, die man sich merken sollte, wenn man beim Patchen „nächste Woche" denkt.

Zum Werkstatt-Teil, denn der ist der Grund für diesen Beitrag. Meine Instanz war nach außen nicht erreichbar — dachte ich. Geglaubt habe ich es aber erst, nachdem ich es von außen probiert hatte: Verbindungsversuch von einer fremden Adresse, Ergebnis „connection refused", erst das zählt. Eine Firewall-Regel, die man im Config-File liest, ist eine Absichtserklärung; ein abgewiesener Verbindungsversuch ist ein Befund. Zusätzlich habe ich den Dienst, der vorher brav auf allen Interfaces lauschte, an die interne Adresse gebunden — dass etwas hinter NAT liegt, ist kein Grund, es breitbeinig dastehen zu lassen. Und diese Woche folgte der letzte Schritt, das Update auf die abgesicherte Version, mit Datenbank-Dump vorweg, denn ein Upgrade ohne Backup ist nur ein Absturz mit Anlauf.

Falls Sie selbst Gitea oder Forgejo im Docker betreiben: Version prüfen, vor 1.26.3 sofort aktualisieren, und danach von außen testen, was von außen geht — nicht in der Config nachlesen, was gehen sollte. Die Angreifer machen gerade genau diesen Test, flächendeckend. Es ist besser, man kommt ihnen zuvor. Der Wettlauf läuft seit dreizehn Tagen.

Quelle: SecurityWeek — Critical Gitea Flaw Under Active Exploitation; Sysdig

Security · ▸ Werkstatt