Viele Unternehmen behandeln ihren internen Git-Server wie pragmatische Entwickler-Infrastruktur: Er läuft im Docker-Container, hängt hinter einem Reverse Proxy, verwaltet ein paar interne Repositories und wird nur dann angefasst, wenn ein Upgrade ohnehin geplant ist. Genau diese Betriebslogik ist beim aktuellen Gitea-Fall gefährlich. Die Schwachstelle CVE-2026-60004 ist nicht nur ein weiterer Eintrag in einer langen Patchliste. CISA hat sie am 25. August 2026 in den Known Exploited Vulnerabilities Catalog aufgenommen, nachdem es Hinweise auf aktive Ausnutzung gab. Help Net Security und The Hacker News berichteten am 26. August über reale Angriffe, bei denen mindestens ein selbst gehosteter Gitea-Server kompromittiert und ein miner-ähnlicher Payload ausgeführt wurde.
Der praktische Punkt ist einfach: Ein Git-Server ist heute kein reines Code-Archiv mehr. Er ist Teil der Software-Lieferkette, oft mit CI/CD, Deploy Keys, Webhooks, Paketregistries, OAuth-Integrationen, Entwickleridentitäten und zunehmend auch KI-gestützten Review- oder Coding-Agenten verbunden. Wenn dort Code ausgeführt werden kann, geht es nicht nur um CPU-Last durch Cryptomining. Es geht um die Integrität der Entwicklungsplattform.
Was technisch passiert
Die Primärquelle ist das GitHub Security Advisory GHSA-rcr6-4jqh-j84m des Gitea-Projekts. Es beschreibt CVE-2026-60004 als Remote Code Execution über die diffpatch-Funktion. Betroffen sind Gitea-Versionen ab 1.17 bis vor 1.27.1; behoben ist der Fehler ab Version 1.27.1. Die Schwachstelle ist mit CVSS 9.8 als kritisch bewertet und CWE-94, also Code Injection, zugeordnet.
Der Kern liegt in der Art, wie Gitea Patches verarbeitet. Der diffpatch-Endpunkt kann laut Advisory missbraucht werden, um aus repository-kontrolliertem Inhalt einen Git-Hook zu installieren und auszuführen. Ein Angreifer benötigt dafür normalerweise Schreibrechte auf ein Repository. Diese Einschränkung ist in vielen Deployments weniger beruhigend, als sie klingt: Wenn offene Registrierung aktiviert ist, kann ein externer Besucher ein normales Konto anlegen, ein Repository erstellen und damit die benötigten Schreibrechte selbst erzeugen.
Das Advisory nennt auch wichtige Betriebsbedingungen: relevant sind Git 2.32 oder neuer, ein aktivierter diffpatch-Pfad und ein temporäres Dateisystem, auf dem geschrieben und ausgeführt werden kann. Der erfolgreiche Angriff läuft mit den Rechten des Gitea-Betriebssystembenutzers, häufig also als dedizierter git-User. Das ist nicht automatisch Root. Es reicht aber, um sensible Plattformdaten zu gefährden.
Warum die Auswirkung über „Container kompromittiert“ hinausgeht
Die Gitea-Maintainer weisen ausdrücklich darauf hin, dass erfolgreiche Ausnutzung je nach Isolation und Rechten des Dienstkontos app.ini, Anwendungsschlüssel, Prozessumgebungsvariablen, gemountete Repositories, Datenbankzugänge, Datenbankinhalte sowie OAuth- und Integrations-Credentials offenlegen kann. Genau hier liegt das Unternehmensrisiko.
Ein Gitea-Container ist oft nicht privilegiert. Trotzdem enthält oder erreicht er häufig Informationen, die für Angreifer wertvoller sind als der Host selbst: Repository-Inhalte, Webhook-Secrets, Tokens für Build-Systeme, SSH- oder Deploy-Schlüssel, interne Paketquellen und Konfigurationen. In modernen Entwicklungsumgebungen können zudem KI-Agenten oder automatische Review-Workflows an diese Repositories angeschlossen sein. Manipulierter Code, manipulierte Issues oder geänderte Workflow-Dateien können dann nicht nur Menschen, sondern auch Automatisierungssysteme beeinflussen.
Die aktuelle Ausnutzung zeigt, dass dieses Risiko nicht theoretisch bleibt. Help Net Security verweist auf einen Habr-Incident-Report: Ein Betreiber wurde durch seinen Hoster auf dauerhaft hohe CPU-Last aufmerksam. Der Server lief mit einer veralteten Gitea-Version, offener Registrierung, ohne E-Mail-Bestätigung und ohne CAPTCHA. Ein automatisierter Scanner konnte ein Konto registrieren, ein Repository anlegen und die Ausführungskette starten. Der Angriff lief über HTTPS; ein nicht exponierter SSH-Port hätte diesen Pfad also nicht verhindert.
Was über die Angriffe bekannt ist – und was nicht
CISA bestätigt durch die KEV-Aufnahme aktive Ausnutzung, veröffentlicht aber keine Details zu Kampagne, Akteur oder Umfang. Die Behörde setzte für US-Bundesbehörden eine Frist bis zum 28. August 2026. Das ist ein starkes Signal für Priorität, aber keine öffentliche Opferstatistik.
Der öffentlich beschriebene Einzelvorfall deutet auf Cryptojacking hin, sollte aber sauber eingeordnet werden. Laut Help Net Security schrieb der Angriff zunächst einen RCE-Nachweis in einen Git-Branch, lud dann einen universellen Shell-Loader und anschließend einen miner-ähnlichen Dropper. Der Payload konkurrierte um CPU-Ressourcen; die aktive Phase soll etwa elf Sekunden gedauert haben. Gleichzeitig wurde die genaue Miner-Familie, Wallet, Mining-Pool oder Betreiberidentität nicht bestätigt. Seriös formuliert: Es handelt sich um einen miner-ähnlichen Payload und um beobachtete Ausnutzung, nicht um eine belastbar attributierte Massenkampagne.
Ebenso wichtig: Der im Incident beschriebene Container war nicht privilegiert, und nach Neustarts blieb der miner-ähnliche Prozess offenbar nicht bestehen. Es wurden dort keine Spuren für Persistenz über Cron, systemd oder neue SSH-Keys gefunden. Das darf Unternehmen aber nicht in falscher Sicherheit wiegen. Andere Deployments können mehr Secrets, mehr Netzwerkzugang oder schlechtere Isolation besitzen.
Konkrete Implikationen für Unternehmen
Erstens: Versionen prüfen und aktualisieren. Alle selbst gehosteten Gitea-Instanzen unter 1.27.1 gehören auf eine behobene Version; Gitea 1.27.2 war zum Zeitpunkt der Berichte bereits als aktuelle Version genannt. Wichtig ist die laufende Instanz, nicht nur die Compose-Datei oder das Image im Registry-Cache.
Zweitens: Offene Registrierung und Signup-Pfade prüfen. Für interne Git-Plattformen ist DISABLE_REGISTRATION = true in vielen Umgebungen der erwartete Zielzustand. Wo Self-Service nötig ist, gehören E-Mail-Bestätigung, CAPTCHA, SSO-Grenzen, Einladungsflüsse und Rate Limits auf den Prüfstand. Offene Registrierung ist nicht die eigentliche Schwachstelle, macht aus einem schreibrechtepflichtigen Angriff aber einen extern erreichbaren Angriffspfad.
Drittens: Netzwerkgrenzen nachziehen. Gitea-Weboberfläche und API sollten nicht unnötig internetweit erreichbar sein. Reverse Proxies, VPN, Zero-Trust-Zugänge, IP-Allowlisting und getrennte Admin-Pfade sind keine Ersatz-Patches, reduzieren aber die Zahl der Angreifer, die den verwundbaren Pfad erreichen.
Viertens: Egress kontrollieren. Der gemeldete Angriff konnte Payloads nachladen. Für einen Git-Server ist unbegrenzter ausgehender Internetzugang selten erforderlich. Container- und Firewall-Regeln sollten Downloads, DNS, direkte HTTP(S)-Egress-Pfade und Verbindungen zu unbekannten Hosts begrenzen und protokollieren.
Fünftens: Nach Kompromittierung suchen, nicht nur patchen. Relevante Fragen sind: Wurden seit Ende Juli unbekannte Nutzer angelegt? Gibt es neue Repositories, auffällige diffpatch-API-Aufrufe, ungewöhnliche Branches, ausführbare Hook-Dateien, Prozesse des Gitea-Users mit Shell- oder Download-Aktivität, CPU-Spitzen oder ausgehende Verbindungen? Außerdem sollten app.ini, Datenbank-Credentials, OAuth-Secrets, Webhook-Secrets, Deploy Keys, Runner-Tokens und persönliche Zugriffstokens rotiert werden, wenn ein Treffer plausibel ist.
Branchenkontext: DevOps-Plattformen sind Kontrollflächen
Der Fall passt in ein Muster der letzten Monate: Selbst gehostete Entwicklungsplattformen, CI/CD-Workflows und Automatisierungsdienste werden zu Angriffszielen, weil sie Rechte bündeln. Ein Angreifer, der dort ausführen oder schreiben kann, muss nicht sofort Produktionsserver übernehmen. Es reicht, Build-Artefakte, Releases, Dependencies, Pull Requests oder Agenten-Kontext zu beeinflussen.
Für KI-gestützte Entwicklung verschärft sich das noch. Coding-Agenten lesen Repositories, Issues und Logs nicht passiv wie Menschen, sondern können daraus Aktionen ableiten: Tests starten, Fixes vorschlagen, Dateien ändern oder Workflows anstoßen. Ein kompromittierter Git-Dienst ist deshalb auch eine Quelle vergifteten Kontexts. Die richtige Lehre lautet nicht, KI-Agenten abzuschalten. Die Lehre lautet, Git-, CI- und Agenten-Rechte gemeinsam zu modellieren.
Fazit
CVE-2026-60004 ist ein nüchterner, aber dringender Patch- und Prüfauftrag. Gitea vor 1.27.1 kann über den diffpatch-Pfad zur Codeausführung gebracht werden; mit offener Registrierung kann ein externer Angreifer die nötigen Schreibrechte selbst erzeugen. Die KEV-Aufnahme durch CISA und die gemeldete miner-ähnliche Ausnutzung machen daraus ein aktuelles Betriebsrisiko.
Unternehmen sollten jetzt nicht nur „Update erledigt“ abhaken. Sie sollten ihre Gitea-Exposition, Registrierungslogik, Container-Isolation, Egress-Regeln, Secrets und Logs prüfen. Wer selbst gehostete DevOps-Infrastruktur betreibt, betreibt einen Teil der Software-Lieferkette. Genau so sollte sie geschützt werden.
Quellen: GitHub Security Advisory GHSA-rcr6-4jqh-j84m / CVE-2026-60004; Gitea Release 1.27.1; CISA Alert vom 25. August 2026 zur KEV-Aufnahme; Help Net Security, „Critical Gitea vulnerability now exploited in the wild“, 26. August 2026; The Hacker News, „Critical Gitea RCE Actively Exploited as Reported Attack Drops Miner-Like Payload“, 26. August 2026.
