CISA bestätigt aktive Ausnutzung von CVE 9,8 in Gitea, mit Minern, die über den Endpoint diffpatch eindringen

Was die CISA in den KEV aufgenommen hat

Die CISA fügte am Dienstag, dem 25. August, die CVE-2026-60004 dem Katalog der Bekannten Ausgenutzten Schwachstellen hinzu, und die darauf folgende Woche brachte die ersten öffentlichen Bestätigungen über die Ausnutzung in Produktionsumgebungen der selbst gehosteten Code-Hosting-Plattform Gitea. Der Fehler, mit einem CVSS von 9,8, erlaubt es einem Angreifer mit Schreibberechtigung in einem beliebigen Repository, einen bösartig formatierten Patch an den Endpoint diffpatch zu senden und einen ausführbaren Git-Hook zu implantieren, der beliebige Shell-Befehle mit den Rechten des Gitea-Prozesses ausführt.

Die Sicherheitslücke wurde am 27. Juli von den Maintainers mit dem Release 1.27.1 behoben, und die Sicherheitswarnung wurde am folgenden Tag veröffentlicht. Zwischen der Veröffentlichung und der Aufnahme in den KEV verfolgten unabhängige Forscher automatisierte Scans in Honeypots, ohne öffentliche Berichte über tatsächliche Kompromittierungen. Die Situation änderte sich, als ein russischer Administrator im Habr ein Protokoll seiner eigenen gehackten Instanz veröffentlichte. Der Bericht beschrieb einen zweistufigen Payload: einen universellen Shell-Loader gefolgt von einem Dropper mit dem Verhalten eines Kryptowährungs-Miners, der innerhalb des Gitea-Containers als Benutzer git ausgeführt wird.

Amerikanische Bundesbehörden müssen bis spätestens Freitag, den 28. August, patchen, eine verbindliche Frist für die gesamte Infrastruktur des Bundeszivilen Exekutivzweigs. Außerhalb der US-Regierung gilt die CISA-Anleitung als Empfehlung ohne formelle Frist.

Warum der Fehler diejenigen betrifft, die Gitea "sicher" betrieben

Die übliche Praxis in DevSecOps ist es, die Angriffsfläche von Gitea zu verringern, indem man die Instanz hinter einem VPN oder einem Bastion betreibt und das selbst gehostete Repository als vertrauenswürdig behandelt. Die CVE-2026-60004 stellt diese Annahme jedoch in zweifacher Hinsicht in Frage.

Erstens, der Vektor erfordert nur Schreibzugriff auf ein beliebiges Repository. In Instanzen mit standardmäßig offenem Registrierungsprozess, was die offizielle Dokumentation für kleine Teams empfiehlt, kann jedes Konto in Sekunden ein eigenes Repository erstellen und wird zu einem authentifizierten Angreifer. Der Bericht im Habr beschrieb genau diese Kette: Ein Scanner registrierte ein Konto, erstellte ein eigenes Repository, führte den Exploit aus, schrieb einen Proof of Concept zurück in den Hauptbranch und startete den Dropper.

Zweitens, der implantierte Git-Hook wird innerhalb des Gitea-Prozesses ausgeführt, der in den meisten Installationen als systemd-Dienst mit Zugriff auf interne Datenbanken, SSH-Schlüssel und CI-Tokens läuft. Der Aufstieg zu einer Build-Pipeline ist sofortig, und wer Gitea in Kubernetes mit AWS- oder GCP-Anmeldeinformationen betreibt, die über IRSA oder Workload Identity bereitgestellt werden, setzt potenziell das gesamte Cloud-Konto dem gleichen Angreifer aus, der über die öffentliche Registrierung eingedrungen ist.

Wo der Einfluss am schwersten wiegt

Gitea wird als Alternative zu GitHub Enterprise in drei Kundentypen betrachtet. Der erste ist das Infrastrukturteam, das aus regulatorischen Gründen den Code innerhalb des Perimeters halten muss, was in deutschen Banken unter der Aufsicht der BaFin und bei Beratungsunternehmen mit government-adjacent Verträgen im Vereinigten Königreich üblich ist. Der zweite ist die indische Betriebsstätte in Outsourcing-Anbietern, die Repositories für mehrere Kunden unter derselben Instanz hosten. Der dritte ist das lateinamerikanische Startup, das alles auf einer einzigen VPS laufen lässt, um Kosten zu sparen.

In Deutschland ist Gitea die bevorzugte Plattform für Teams, die vermeiden wollen, dass Code auf Server außerhalb der Europäischen Union übertragen wird, und die Aussetzung durch die CVE-2026-60004 zwingt zu einer Überprüfung des Risikos in Verträgen, die eine SLA von 72 Stunden für die Eindämmung vorsehen. In den Lieferzentren von TCS, Infosys und Wipro in Pune, Bengaluru und Manila ist Gitea eine der genehmigten Plattformen für Kunden mit Air-Gap-Politik, und eine Kompromittierung in dieser Basis kann je nach Tenant-Segmentierung leichte bis schwere Auswirkungen haben.

In Brasilien ist die Situation anders. Nubank, Stone und die Technologieabteilungen großer Banken arbeiten überwiegend mit GitHub Enterprise oder GitLab, aber mittelständische Integratoren und staatliche Technologieabteilungen halten weiterhin Gitea-Instanzen. Die praktische Empfehlung ist die gleiche: auf 1.27.2 aktualisieren und die Protokolle seit dem 27. Juli prüfen.

Was zu überprüfen ist, bevor man eine Eindämmung als abgeschlossen betrachtet

Das Sicherheitsteam, das bereits den Patch angewendet hat, muss drei Mindestüberprüfungen durchführen, um eine frühere Kompromittierung auszuschließen. Erstens, alle Git-Hooks auflisten, die nach dem 27. Juli in allen Repositories der Instanz erstellt wurden, mit besonderem Augenmerk auf Skripte, die Netzwerk-Sockets öffnen oder externe Artefakte herunterladen. Zweitens, den Verlauf der in diesem Zeitraum über die offene Registrierung erstellten Konten überprüfen und mit der unmittelbaren Erstellung von Repositories, die einen anomalem Patch enthalten, korrelieren. Drittens, aktive Prozesse im Gitea-Container auf gängige Cryptominer-Signaturen überprüfen, beginnend mit XMRig.

Die Dokumentation von Gitea enthält eine vierte Aktion, die oft vergessen wird: das Deaktivieren der offenen Registrierung, wenn es keinen expliziten Grund gibt, dies aufrechtzuerhalten. Instanzen mit öffentlicher Anmeldung bleiben der günstigste Vektor für einen externen Angreifer, und die CVE-2026-60004 ist nicht die erste und wird nicht die letzte sein, die diese Standardkonfiguration ausnutzt. Wenn das nächste kritische Gitea-Bug auftaucht, wird die Reaktionskosten proportional zu den anonymen Konten sein, die diese Woche im System verblieben sind.