Gitea-Lücke wird ausgenutzt – ein Angriff dauert nur 11 Sekunden

Die kritische Gitea-Schwachstelle CVE-2026-60004 gilt seit dem 25. August 2026 als aktiv ausgenutzt. An diesem Tag nahm CISA sie in den KEV-Katalog auf; die Warnung des kanadischen Cyber Centre nennt selbst gehostete Installationen vor Version 1.27.1 als gefährdet.

Wie schnell ein erreichbarer Server kompromittiert werden kann, zeigt ein dokumentierter Angriff: Vom Öffnen der Registrierung bis zum Abruf des Nachweises einer Befehlsausführung vergingen etwa elf Sekunden. Der Incident-Bericht des betroffenen Betreibers belegt die Kette mit Anwendungslogs, Git-Objekten und Dateispuren; anschließend wurde ein miner-ähnlicher Dropper nachgeladen.

Welche Versionen betroffen sind

Die präzise Versionsgrenze reicht von Gitea 1.17 bis einschließlich 1.27.0. Der offizielle Gitea-Advisory stuft die Schwachstelle als kritisch ein und führt 1.27.1 als erste korrigierte Version auf. Ältere Ausgaben vor 1.17 fallen nicht in den dort angegebenen verwundbaren Bereich.

Version 1.27.1 ist damit die technische Untergrenze für die Korrektur. Betreiber sollten jedoch auf eine aktuelle, gepflegte Ausgabe aktualisieren und anschließend kontrollieren, welche Version tatsächlich läuft. Bei Container-Installationen genügt es nicht, nur eine Image-Definition oder Paketquelle zu ändern, wenn der aktive Container weiterhin eine verwundbare Ausgabe verwendet.

Das Update schließt die bekannte Angriffsmöglichkeit, beseitigt aber keine Folgen einer früheren Kompromittierung. War eine verwundbare Instanz öffentlich erreichbar, muss deshalb nachvollzogen werden, bis wann die alte Version aktiv war und ob in diesem Zeitraum verdächtige Konten, Repositories oder Anfragen auftauchten.

Wie Repository-Schreibzugriff zur Codeausführung führt

Der Angriff nutzt den Gitea-Endpunkt diffpatch. Zwei entsprechend präparierte Patch-Vorgänge können in einem temporären Bare-Repository eine ausführbare Datei unter hooks/post-index-change entstehen lassen. Git ruft diesen Hook beim Schreiben des Index auf; seine Befehle laufen mit den Rechten des Gitea-Dienstkontos.

Vorausgesetzt werden gewöhnlicher Schreibzugriff auf ein Repository, Git ab Version 2.32, eine aktivierte diffpatch-Route sowie ein beschreibbares und ausführbares temporäres Dateisystem. Offene Registrierung ist nur für den Angriffsweg ohne vorher vorhandene Zugangsdaten nötig: Ein Besucher kann dann ein normales Konto und ein eigenes Repository anlegen und sich so den erforderlichen Schreibzugriff verschaffen. Zugriff auf bestehende Projekte ist dafür nicht notwendig.

Im beobachteten Fall legte die Angriffskette zunächst eine Branch mit dem Ergebnis des Befehls id an. Der Scanner konnte den RCE-Nachweis anschließend über Gitea selbst abrufen; für diesen Schritt war keine separate Rückverbindung erforderlich. Danach startete der Hook im Hintergrund einen Loader, der mehrere vorhandene Programme zum Herunterladen der nächsten Stufe ausprobierte.

Vier Faktoren bestimmen die Dringlichkeit

Für die erste Einstufung einer Instanz sind Versionsstand, Registrierung, Prozessrechte und ausgehende Verbindungen gemeinsam zu betrachten:

1. Läuft Gitea 1.17 bis 1.27.0? Dann ist die bekannte Schwachstelle vorhanden. Auch nach einem Update bleibt relevant, wie lange die verwundbare Version öffentlich erreichbar war.
2. War die Selbstregistrierung geöffnet? Dann konnte ein externer Besucher den benötigten Repository-Schreibzugriff selbst erzeugen. Bei geschlossener Registrierung kommen weiterhin kompromittierte oder regulär berechtigte Konten als Ausgangspunkt infrage.
3. Worauf kann der Gitea-Prozess zugreifen? Gemountete Repositories, Konfigurationsdateien, Umgebungsvariablen, Datenbankzugänge und interne Dienste bestimmen den möglichen Schaden. Ein unprivilegierter Container reduziert die Reichweite, beweist aber keine Unversehrtheit.
4. Darf der Prozess beliebige externe Ziele erreichen? Uneingeschränkter ausgehender Verkehr erleichtert das Nachladen weiterer Komponenten. Eine gezielte Allowlist kann diesen Folgeschritt begrenzen, verhindert jedoch nicht die ursprüngliche Befehlsausführung.

Die höchste Priorität hat somit eine ungepatchte, öffentlich erreichbare Instanz mit offener Registrierung, weitreichenden Containerzugriffen und freiem Internet-Egress. Eine isolierte Instanz ohne Selbstregistrierung bietet weniger Angriffsfläche von außen, bleibt innerhalb des verwundbaren Versionsbereichs aber update- und prüfpflichtig.

Welche Spuren und Geheimnisse geprüft werden sollten

Vor dem Ersetzen eines Containers oder dem Bereinigen temporärer Dateien sollten relevante Logs und Artefakte unverändert gesichert werden. Ein Neustart kann flüchtige Prozesse beenden und Spuren im temporären Dateisystem verlieren lassen.

• HTTP- und Gitea-Logs auf neue Registrierungen, unmittelbar folgende Repository-Erstellungen, wiederholte Aufrufe von /diffpatch und Abrufe ungewöhnlicher Branches oder Dateien prüfen.
• Unerwartete Konten, Repositories, Access Tokens, Deploy Keys, OAuth-Anwendungen und Webhooks mit dem bekannten Änderungsverlauf abgleichen.
• Temporäre Verzeichnisse, Git-Hooks, unbekannte Prozesse und gelöschte, aber noch geöffnete Dateien untersuchen. Auffällige CPU-Last ist ein mögliches Signal; ihr Fehlen schließt einen früheren Angriff nicht aus.
• Container-, Host- und Netzwerkprotokolle auf ausgehende Verbindungen sowie Aufrufe von curl, wget, Python oder Perl durch den Gitea-Prozess kontrollieren.
• Alle für den kompromittierbaren Prozess erreichbaren Geheimnisse rotieren, darunter Anwendungs- und Datenbankpasswörter, OAuth- und Integrationstokens sowie CI/CD-Zugangsdaten.

Die Rotation muss auch abhängige Systeme erreichen: Ein geändertes Datenbankpasswort widerruft beispielsweise keine separat ausgestellten Tokens oder Deploy Keys. Registrierung, zusätzliche Anmeldewege, Container-Mounts und ausgehende Netzwerkfreigaben sollten anschließend auf das betrieblich notwendige Maß reduziert werden.

Was über die Angriffe noch nicht bekannt ist

Bestätigt sind die Aufnahme in den KEV-Katalog und mindestens ein detailliert belegter Angriff mit automatisiert wirkender, rund elf Sekunden langer Exploit-Phase. Öffentlich ungeklärt bleibt, ob dieser konkrete Vorfall für die CISA-Einstufung ausschlaggebend war, wie viele Instanzen kompromittiert wurden und wer hinter den Angriffen steht.

Auch die nachgeladene Komponente lässt sich nur als miner-ähnlicher Dropper bezeichnen. Verhalten und CPU-bezogene Funktionen passen zu Cryptojacking, doch die nachfolgenden Binärdateien wurden im dokumentierten Fall nicht vollständig analysiert; Mining-Pool, Wallet, Malware-Familie und Betreiber sind daher nicht bestätigt. Für betroffene Teams bleibt die Lage eindeutig: Die Version muss korrigiert und eine frühere Exposition wie ein möglicher Sicherheitsvorfall untersucht werden.