Gitea CVE-2026-60004: Kritische RCE wird aktiv ausgenutzt

Betroffen sind Gitea-Versionen ab 1.17 bis einschließlich 1.27.0. Über die diffpatch-API kann ein Angreifer mit Schreibzugriff auf ein Repository einen ausführbaren Git-Hook einschleusen und dadurch Shell-Kommandos mit den Rechten des Gitea-Systemkontos ausführen. Gitea 1.27.1 schließt die Schwachstelle. CISA bestätigte die aktive Ausnutzung am 25. August 2026 und setzte US-Bundesbehörden eine Frist bis zum 28. August 2026. Der genannte CVSS-Wert von 9,8 stammt aus dem GitHub Advisory und Fachberichten. Erste Priorität haben Versionsprüfung, Update und Kontrolle öffentlich erreichbarer Instanzen.

Gesichert sind der Angriffspfad, die betroffenen Versionen, die Korrektur in 1.27.1 und die Aufnahme in den CISA-KEV-Katalog. Ebenfalls dokumentiert ist ein einzelner öffentlich beschriebener Vorfall, bei dem ein Angreifer nach offener Selbstregistrierung einen Miner-ähnlichen Payload in einem Gitea-Container startete. Nicht gesichert ist, ob dieser Vorfall die KEV-Aufnahme auslöste oder welche Gruppen weitere Angriffe durchführen. Betreiber sollten bei ungepatchten und öffentlich erreichbaren Systemen von einem möglichen Sicherheitsvorfall ausgehen, nicht nur von einer Patch-Aufgabe.

Betroffene Versionen und Fix

Die Schwachstelle trägt die Kennung CVE-2026-60004 und betrifft den diffpatch-Endpunkt von Gitea. Laut dem offiziellen GitHub Security Advisory sind Versionen von 1.17 bis einschließlich 1.27.0 verwundbar. Die korrigierte Version 1.27.1 wurde Ende Juli 2026 veröffentlicht. Ältere Installationen sollten nicht allein durch eine vorgeschaltete Anmeldung als sicher gelten, weil bereits gewöhnlicher Repository-Schreibzugriff für den Angriff genügt.

Prüfpunkt	Bewertung	Erforderliche Aktion
Gitea 1.17 bis 1.27.0	Verwundbar	Sofort auf 1.27.1 oder neuer aktualisieren
Gitea 1.27.1 oder neuer	Patch enthalten	Version verifizieren und Logs prüfen
Offene Selbstregistrierung	Erhöhtes Risiko	Deaktivieren oder streng absichern
Öffentlich erreichbare Instanz	Hohe Exposition	Incident-Response-Prüfung einplanen
Container-Betrieb	Begrenzt nicht automatisch den Schaden	Secrets, Mounts und Berechtigungen prüfen

Wer Gitea selbst betreibt, findet die eingesetzte Version in der Administrationsoberfläche oder der Container-Kennzeichnung. Bei Docker-Deployments sollte das Image nicht nur neu geladen, sondern der Dienst mit dem aktualisierten Image neu erstellt werden. Ein bloßer Neustart des alten Containers ändert die Gitea-Version nicht.

So funktioniert der Angriff

Der diffpatch-Endpunkt verarbeitet Patches in einem temporären Git-Repository. Der veröffentlichte technische Nachweis beschreibt, wie ein präparierter Patch durch das Zusammenspiel von git apply --cached und einem Drei-Wege-Fallback dennoch Dateien in den Arbeitsbereich schreiben kann. Da das temporäre Repository als Bare-Repository angelegt ist, kann ein Angreifer einen Pfad unter hooks/ treffen. Wird dort ein ausführbarer Hook abgelegt, startet Git diesen bei einer nachfolgenden Index-Aktion.

Der Angreifer benötigt keine Gitea-Administratorrechte. Ist die öffentliche Registrierung aktiviert und dürfen neue Konten eigene Repositories anlegen, kann ein externer Besucher zunächst ein gewöhnliches Konto erstellen und anschließend selbst die notwendige Ausgangsposition schaffen.

• Der Angreifer benötigt Schreibzugriff auf mindestens ein Repository.
• Ein bösartig aufgebauter Patch wird an die diffpatch-API gesendet.
• Der Patch platziert einen ausführbaren Git-Hook im temporären Repository.
• Eine weitere Git-Aktion löst den eingeschleusten Hook aus.
• Die Befehle laufen mit den Rechten des Gitea-Servicekontos.

Warum die Lücke kritisch ist

Remote Code Execution als Gitea-Systemnutzer bedeutet nicht automatisch Root-Rechte. Die Wirkung kann trotzdem weit über das betroffene Repository hinausreichen. Das Dienstkonto hat typischerweise Zugriff auf Gitea-Konfiguration, Repository-Daten, Datenbankverbindungen und Integrationsgeheimnisse. In CI/CD-Umgebungen können zusätzlich Tokens, Deploy-Schlüssel oder Zugangsdaten für Paketregistries erreichbar sein.

• Alle gehosteten Repositories können für das Dienstkonto erreichbar sein.
• Konfigurationsdateien können Datenbank- und OAuth-Zugangsdaten enthalten.
• CI/CD-Secrets können nachgelagerte Produktionssysteme gefährden.
• Manipulierter Quellcode kann über reguläre Build-Prozesse verteilt werden.
• Hohe CPU-Last kann auf unerlaubtes Cryptomining hinweisen.

Aktive Ausnutzung und Cryptojacking

CISA nahm CVE-2026-60004 am 25. August 2026 in den Katalog der nachweislich ausgenutzten Schwachstellen auf. Die KEV-Aufnahme bestätigt, dass Ausnutzung außerhalb von Testumgebungen beobachtet wurde, belegt aber nicht automatisch Umfang, Täter oder Zielsetzung sämtlicher Angriffe.

Help Net Security beschreibt einen öffentlich dokumentierten Vorfall bei einer veralteten Gitea-Instanz mit offener Registrierung, ohne E-Mail-Bestätigung und ohne CAPTCHA. Nach dem Anlegen eines Kontos und eines eigenen Repositorys führte der Angreifer Code im Container als Git-Nutzer aus. Der Ablauf umfasste einen RCE-Nachweis, einen Shell-Loader und einen Miner-ähnlichen Dropper. Der nicht privilegierte Container begrenzte in diesem Fall offenbar die Persistenz, was nicht bedeutet, dass Container grundsätzlich ausreichend schützen.

Unklar bleibt, ob CISA genau diesen Vorfall als Grundlage der KEV-Aufnahme nutzte. The Hacker News weist ausdrücklich auf diese offene Frage hin. Cryptojacking wird hier deshalb als dokumentierter Einzelfall eingeordnet, nicht als einziges oder allgemein bestätigtes Angriffsziel.

Was Admins jetzt tun sollten

Die kurze CISA-Frist unterstreicht die Dringlichkeit. Betreiber sollten das Update nicht bis zum nächsten regulären Wartungsfenster verschieben. Besonders öffentlich erreichbare Instanzen mit Selbstregistrierung müssen sofort priorisiert werden.

1. Installierte Gitea-Version auf allen Instanzen inventarisieren.
2. Betroffene Systeme auf Gitea 1.27.1 oder eine neuere Version aktualisieren.
3. Öffentliche Selbstregistrierung vorübergehend deaktivieren, falls sie nicht zwingend benötigt wird.
4. Rechte zum Erstellen und Beschreiben von Repositories auf notwendige Konten begrenzen.
5. Gitea-, Reverse-Proxy- und Systemprotokolle auf neue Konten und ungewöhnliche API-Aufrufe prüfen.
6. Prozesse des Gitea-Systemnutzers sowie auffällige CPU- und Netzwerklast untersuchen.
7. Bei Verdacht Zugangsdaten, Tokens, Deploy-Schlüssel und Datenbankkennwörter rotieren.
8. Container-Mounts, Umgebungsvariablen und Rechte des Dienstkontos kontrollieren.
9. Repositories und Build-Artefakte auf unerwartete Änderungen prüfen.
10. Backups sichern, bevor kompromittierte Systeme bereinigt oder neu aufgebaut werden.

Incident Response bei ungepatchten Systemen

Ein nachträgliches Update entfernt mögliche Hintertüren oder gestohlene Zugangsdaten nicht. War eine verwundbare Instanz öffentlich erreichbar, sollte das Team den Zeitraum zwischen Veröffentlichung des Proof of Concept und dem Update untersuchen. Neue Konten, unerwartete Repository-Erstellungen und Aufrufe des diffpatch-Endpunkts verdienen besondere Aufmerksamkeit.

Bei Auffälligkeiten ist eine isolierte forensische Sicherung sinnvoll. Danach sollten Betreiber die Instanz aus vertrauenswürdigen Quellen neu aufbauen und alle potenziell erreichbaren Secrets ersetzen, einschließlich Container-Registries, Cloud-Konten und Deployment-Zielen.

Ein früherer Fall, Gitea Actions CVE-2026-58426, betraf eine andere Schwachstelle mit Cross-Repository-Zugriff auf Build-Artefakte. Beide Fälle zeigen, dass Berechtigungen und Secrets rund um selbst gehostete Entwicklungsplattformen regelmäßig überprüft werden sollten.

Dauerhafte Härtung von Gitea

Nach dem Notfall-Update lohnt sich eine Überprüfung des Betriebsmodells. Gitea sollte unter einem eigenen, möglichst unprivilegierten Systemkonto laufen, ohne allgemeinen Shell-Zugang und mit minimalen Verzeichnisrechten. Container dürfen nicht privilegiert gestartet werden.

• Selbstregistrierung nur aktivieren, wenn ein klarer Geschäftsbedarf besteht.
• E-Mail-Bestätigung und weitere Registrierungsbarrieren verwenden.
• Administrative Oberfläche und API über Firewall oder VPN begrenzen.
• Updates und Security Advisories regelmäßig überwachen.
• Backups getrennt speichern und Wiederherstellung testen.
• Secrets nicht dauerhaft in Repositories oder ungeschützten Variablen ablegen.

Passende Anleitungen auf S-EDV

• Gitea mit Docker als eigenen Git-Server betreiben
• Docker-Container-Updates mit DIUN und WUD überwachen
• Gitea Actions CVE-2026-58426: Cross-Repository-Zugriff

Quellen

• Gitea GitHub Security Advisory GHSA-rcr6-4jqh-j84m
• CISA: Aufnahme von CVE-2026-60004 in den KEV-Katalog
• SecurityWeek: CISA warnt vor ausgenutzter Gitea-Schwachstelle
• Help Net Security: Dokumentierter Angriff mit Miner-ähnlichem Payload
• The Hacker News: Aktive Ausnutzung von CVE-2026-60004