CISA nimmt Gitea-Schwachstelle in den KEV-Katalog auf: Ausgenutzt für Codeausführung und Installation von Minern

Die Aufnahme in den KEV und die Frist bis zum 28. August

Am 25. August 2026 hat die Cybersecurity and Infrastructure Security Agency (CISA) die Schwachstelle CVE-2026-60004 in den Katalog bekannter ausgenutzter Schwachstellen (Known Exploited Vulnerabilities, KEV) aufgenommen. Die Aufnahme basiert auf Belegen für aktive Ausnutzung.

Die Frist für die Behebung durch die zivilen Bundesbehörden der USA (FCEB) ist auf den 28. August 2026 festgelegt. Es handelt sich um ein Zeitfenster von drei Tagen, im Einklang mit der Betriebsanweisung BOD 26-04, die eine schnelle Behebung von Hochrisiko-Schwachstellen vorschreibt, wenn diese die vollständige Kontrolle über einen exponierten Vermögenswert ermöglichen.

Die Schwachstelle betrifft Gitea, eine Open-Source-Plattform für das Hosting und die Verwaltung von Git-Repositories, die häufig als selbst gehostete Alternative zu GitHub oder GitLab eingesetzt wird. CISA stuft sie als Schwachstelle der Code-Injektion ein und weist darauf hin, dass sie ein häufiger Angriffsvektor für böswillige Akteure ist.

Wie die Schwachstelle funktioniert: Vom bösartigen Patch zur Befehlsausführung

Die aus dem National Vulnerability Database (NVD) paraphrasierte technische Beschreibung besagt, dass Gitea eine Code-Injection-Schwachstelle enthält. Ein Angreifer mit Schreibzugriff auf ein Repository kann einen bösartigen Patch an den Endpunkt diffpatch API senden.

Über diese API ist es möglich, einen ausführbaren Git-Hook zu installieren und die Ausführung von Shell-Befehlen als Dienstkonto von Gitea zu erlangen. In der Praxis muss der Angreifer den Server nicht direkt kompromittieren: Es genügt, wenn er ein Repository erstellen oder ändern kann.

Ein kritischer Punkt, der von der journalistischen Quelle SecurityAffairs gemeldet wird, ist, dass Gitea die offene Registrierung standardmäßig aktiviert. Folglich kann ein nicht authentifizierter Angreifer ein Konto erstellen, ein Repository anlegen und die Schwachstelle ausnutzen, ohne über bereits vorhandene Zugangsdaten zu verfügen.

Betroffene Versionen und Behebung: Die Lage bleibt unklar

Die genauen betroffenen Versionen werden weder in der CISA-Meldung noch im verfügbaren NVD-Datensatz genannt. Laut SecurityAffairs betrifft die Schwachstelle Gitea ab Version 1.17 und wurde in Version 1.27.1 behoben.

Die Angabe zu den Versionen stammt daher aus einer einzigen journalistischen Quelle. Sie ist derzeit nicht durch offizielle Dokumentation des Gitea-Projekts bestätigt.

Auch der Schweregrad CVSS 9,8 (kritisch) wird ausschließlich von SecurityAffairs berichtet. Die offiziellen Auszüge aus NVD und CISA enthalten weder den CVSS-Vektor noch die CWE-Klassifizierung. Die beschriebene Auswirkung ist jedoch die Remotecodeausführung als Gitea-Dienstbenutzer, was mit einer kritischen Schwere übereinstimmt.

Beobachteter Angriff: Offene Registrierung und Miner

SecurityAffairs berichtet von einem beobachteten Angriff, bei dem die Schwachstelle ausgenutzt wurde, um eine Nutzlast ähnlich einem Kryptowährungs-Miner zu verteilen. Die kompromittierte Gitea-Instanz war im Internet exponiert und erlaubte sowohl die offene Registrierung als auch den anonymen Zugriff auf die Weboberfläche.

Dieses Szenario senkt die Einstiegshürde: Der Angreifer muss keine Zugangsdaten stehlen oder ein bestehendes Konto kompromittieren. Es genügt, eine verwundbare Instanz mit offener Registrierung zu erreichen, ein Konto und ein Repository zu erstellen und dann den bösartigen Patch zu senden.

Die Kombination aus öffentlicher Exposition, offener Registrierung und Code-Injection-Schwachstelle macht die Schwachstelle besonders geeignet für automatisierte groß angelegte Angriffe, wie sie etwa Miner oder Botnetze verteilen.

Was zu tun ist: Patches und föderale Anforderungen

Für Organisationen, die Gitea verwenden, besteht die hauptsächliche empfohlene Minderung darin, auf Version 1.27.1 oder höher zu aktualisieren. Auch hier stammt die Angabe zur Fix-Version nur aus der journalistischen Quelle: Die offizielle KEV-Meldung nennt im verfügbaren Ausschnitt keine spezifische Version, sondern verweist auf die Anweisungen des Herstellers.

Die US-Bundesbehörden müssen die BOD 26-04 einhalten: die vom Hersteller bereitgestellten Minderungen anwenden, die Prüfungen zur forensischen Triage durchführen und bei Cloud-Diensten der Anleitung der Direktive folgen oder die Nutzung des Produkts einstellen, wenn keine Minderungen verfügbar sind.

Die BOD 26-04 gilt formal nur für FCEB-Behörden, aber CISA ermutigt alle Organisationen, ein risikobasiertes Schwachstellenmanagement zu übernehmen und den im KEV-Katalog enthaltenen CVEs Priorität einzuräumen.

Es ist eine Abweichung zwischen den Quellen zu vermerken: SecurityAffairs zitiert die frühere BOD 22-01, während die offiziellen Quellen CISA und NVD die BOD 26-04 zitieren. Der aktuelle Verweis der CISA-Meldung ist die BOD 26-04.

CVE-Datensatz „reserviert“ und Abweichungen zwischen den Quellen

Zwei Elemente machen die Informationslage noch unvollständig.

Das erste betrifft den Status des CVE-Datensatzes. Zum Zeitpunkt der Einsichtnahme zeigt die Seite des CVE-Programms (cve.org) CVE-2026-60004 als „RESERVED“: Die ID wurde von einem CNA reserviert, und der Datensatz sollte aktualisiert werden, sobald die Details verfügbar sind. Dies steht im Widerspruch zur bereits veröffentlichten NVD-Beschreibung und den KEV-Daten. Der CVE-Datensatz liefert daher keine zusätzlichen technischen Details.

Das zweite ist eine Unstimmigkeit in der journalistischen Quelle. SecurityAffairs beginnt den Artikel, indem es die Schwachstelle als einen Fehler in Oracle HTTP Server und Oracle WebLogic Server Proxy Plug-in bezeichnet, aber die CVE-Kennung und alle anderen offiziellen Quellen beschreiben eine Schwachstelle in Gitea. Das korrekte Produkt ist Gitea.

Diese Abweichungen ändern nichts an der Substanz: Die Schwachstelle ist real, wurde aktiv ausgenutzt und hat eine sehr nahe Bundesfrist. Wer Gitea-Instanzen betreibt, insbesondere wenn sie mit offener Registrierung exponiert sind, sollte die verwendete Version überprüfen und das Update anwenden, ohne auf die Bestätigung aller technischen Details zu warten.