Gitea Sicherheitslücke CVE-2026-60004: 8.393 Server offen im Netz

Die Gitea Sicherheitslücke CVE-2026-60004 wird derzeit aktiv ausgenutzt. Der Patch liegt seit dem 27. Juli 2026 bereit – trotzdem zählte die Beobachtungsstelle Shadowserver am 27. August 2026 noch 8.393 verwundbare, aus dem Internet erreichbare Instanzen. Angreifer setzen darauf Kryptominer ab. Die US-Behörde CISA hat die Lücke am 25. August in ihren Katalog aktiv ausgenutzter Schwachstellen aufgenommen und ihren Bundesbehörden nur drei Tage zum Patchen gegeben.

Was hinter der Gitea Sicherheitslücke steckt

Gitea ist eine selbst gehostete Alternative zu GitHub, GitLab und Bitbucket – beliebt in kleinen Teams, Homelabs und überall dort, wo Quellcode das Haus nicht verlassen soll. Genau dieser Charme ist hier das Problem.

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

E-Mail-Adresse *

Vorname

Nachname

Der Fehler steckt im diffpatch-Endpunkt der API. Über ihn lässt sich Inhalt aus einem Repository als ausführbarer Git-Hook platzieren. Das Resultat: beliebige Shell-Befehle mit den Rechten des Gitea-Systembenutzers. Das NVD bewertet die Lücke mit einem CVSS-3.1-Wert von 9.8 (kritisch), der Eintrag wurde am 26. August 2026 veröffentlicht. Gemeldet wurde sie von Shai Rod, Sicherheitsforscher bei Salesforce.

• Betroffen: Gitea 1.17 bis vor Version 1.27.1
• Fix: 1.27.1 (27. Juli 2026), aktuell ist 1.27.2
• Status: CISA-KEV seit 25.08.2026, Behördenfrist war der 28.08.2026

Die Registrierungsfalle

Auf dem Papier braucht der Angriff Schreibrechte auf ein Repository. Das klingt beruhigend – ist es aber nicht. Gitea liefert die Selbstregistrierung standardmäßig aktiviert aus. Ein Angreifer legt sich also einfach ein Konto an, erstellt ein eigenes Repository und hat damit genau die Schreibrechte, die er braucht. Deshalb bewertet das NVD die Lücke als „keine Rechte erforderlich“, während das Gitea-Advisory von „gewöhnlichem Schreibzugriff“ spricht. Beide Aussagen passen zusammen, sobald offene Registrierung aktiv ist.

Ein Betroffener hat seinen Fall öffentlich dokumentiert: Der Hoster meldete dauerhaft hohe CPU-Last, die Ursache war ein Miner-artiger Payload. Die aktive Angriffsphase dauerte rund elf Sekunden. Gitea lief im Docker-Container, der Container war nicht privilegiert, der Prozess überlebte den Neustart nicht – Persistenz über cron, systemd oder neue SSH-Keys fand die Untersuchung nicht.

Was das für dich bedeutet

Ein selbst gehosteter Git-Server ist in kleinen Betrieben und Homelabs regelmäßig der am schlechtesten gepflegte Dienst im Haus. Er läuft still, er tut seinen Job, und niemand fühlt sich zuständig. Gleichzeitig ist er Kronjuwelen-Klasse: Quellcode, CI-Tokens, Deploy-Keys, Datenbank-Zugangsdaten in der app.ini, angebundene OAuth-Integrationen. Wer hier Code ausführen kann, steht mitten in der Schatzkammer.

Deshalb ist der Kryptominer aus dem dokumentierten Fall das harmloseste denkbare Ergebnis. Nach einem bestätigten RCE lautet die richtige Frage nicht „läuft noch ein Miner?“, sondern „welche Geheimnisse sind abgeflossen?“. Der betroffene Entwickler hat das übrigens korrekt gehandhabt: Er hat aktualisiert, die offene Registrierung deaktiviert, sämtliche Secrets und Tokens rotiert, das Docker-Netzwerk eingeschnürt und den ausgehenden Internetzugang des Containers blockiert. Genau in dieser Reihenfolge gehört das abgearbeitet.

Und noch eine unbequeme Beobachtung aus 25 Jahren IT: Über 8.000 offene Instanzen einen Monat nach dem Patch bedeuten nicht, dass 8.000 Admins faul sind. Sie bedeuten meistens, dass niemand weiß, dass die Instanz überhaupt noch läuft. Schatten-IT altert schlecht.

Deine Checkliste für heute

• Version prüfen und aktualisieren: Alles unter 1.27.1 ist verwundbar, Ziel ist 1.27.2.
• Selbstregistrierung abschalten, wenn du sie nicht ausdrücklich brauchst – in der app.ini im Abschnitt [service] über DISABLE_REGISTRATION.
• Erreichbarkeit einschränken: Eine private Git-Instanz gehört hinter VPN oder einen Reverse Proxy mit vorgelagerter Authentifizierung, nicht offen ins Netz.
• Nach Verdacht auf Kompromittierung: Git-Hooks aller Repositories prüfen, Secrets rotieren (Datenbank, OAuth, Runner- und Deploy-Tokens) und ausgehenden Verkehr des Containers unterbinden.
• Monitoring: Dauerhaft hohe CPU-Last war im dokumentierten Fall das einzige frühe Signal. Ein simpler Lastalarm hätte gereicht.

Wer Dienste zu Hause oder im Kleinbetrieb selbst betreibt, findet in meinem Ratgeber zu NAS, Heimserver und Selfhosting die Grundlagen für ein Setup, das sich auch nach zwei Jahren noch warten lässt. Dass dieses Muster nicht auf Gitea beschränkt ist, zeigte im Juli der RCE-Exploit gegen ungepatchte GitLab-Server.

Quellen

• NVD – CVE-2026-60004
• Gitea Security Advisory GHSA-rcr6-4jqh-j84m
• CISA – Known Exploited Vulnerabilities Catalog
• BleepingComputer, 28.08.2026
• Help Net Security, 26.08.2026