Gitea Actions CVE-2026-58426: Kritische Lücke erlaubt Cross-Repository-Zugriff auf Build-Artefakte
Am 3. Juli 2026 wurde CVE-2026-58426 mit CVSS 9.6 veröffentlicht, eine Schwachstelle in Gitea Actions Artifacts V4, die Cross-Repository-Zugriffe auf Build-Artefakte und Manipulationen am Upload-Status erlaubt. Selfhosting-Admins sollten die eigene Gitea-Version umgehend prüfen.
Am 3. Juli 2026 wurde die Schwachstelle CVE-2026-58426 in Gitea Open Source Git Server veröffentlicht, die NVD mit CVSS 9.6 einstuft. Betroffen ist die Actions-Komponente und dort das Artifact-Storage-System in der V4-Variante mit signierten URLs. Eine Mehrdeutigkeit in der HMAC-Berechnung erlaubt es, Tokens zu erzeugen, die Artefakte anderer Repositories lesen oder den Upload-Status anderer CI-Tasks manipulieren können. Selfhosting-Admins, die Gitea mit aktivierten Actions betreiben, sollten die Installation kurzfristig auf den aktuellen Sicherheits-Stand bringen.
Was ist passiert?
Gitea signiert Download-URLs für CI/CD-Artefakte mit einem HMAC, um zu verhindern, dass Artefakte zwischen Repositories oder Nutzern ausgetauscht werden. In der V4-Variante der Artefakt-Speicherung kollidieren zwei verschiedene Eingabewerte auf denselben HMAC-Output, sodass ein Angreifer mit Account auf derselben Gitea-Instanz durch gezielte Token-Konstruktion Artefakte anderer Repositories lesen kann, als wären es seine eigenen. Auf demselben Weg lässt sich der Upload-Status anderer Tasks manipulieren, sodass nachgelagerte CI-Schritte glauben, ein Build sei erfolgreich gewesen, obwohl ein Angreifer den Inhalt kontrolliert. Gitea Limited hat als CNA die Schwachstelle am 3. Juli 2026 offiziell bestätigt und in der aktuellen Version einen Patch ausgeliefert.
Wer ist betroffen?
Betroffen sind alle selbst gehosteten Gitea-Instanzen, die Actions aktiviert haben und CI/CD-Workflows ausführen, die Build-Artefakte erzeugen, zwischen Repositories teilen oder in nachgelagerte Deployments einspeisen. Gitea.com, die gehostete Variante, ist nach Herstellerangabe nicht betroffen, weil dort bereits der aktuelle Code-Stand produktiv läuft. Auch Gitea-Installationen ohne aktivierte Actions sind nicht betroffen, weil das fehlerhafte Modul in diesem Fall nie ausgeführt wird. Wer Gitea als reine Git-Plattform ohne CI/CD betreibt, kann den Vorfall zur Kenntnis nehmen, muss aber nicht aktiv patchen.
Wie kritisch ist das?
Mit CVSS 9.6 stuft NVD die Schwachstelle als kritisch ein. Das größte Risiko liegt in der Lieferkette: Werden kompromittierte Artefakte in Deployments eingespeist, kann ein Angreifer produktive Software beeinflussen, ohne dass die regulären Code-Signaturen oder Branch-Protection-Regeln ihn stoppen. In Gitea-Setups mit mehreren Repositories auf einer Instanz reicht dafür ein einzelner kompromittierter Account aus, etwa ein ehemaliger Mitarbeiter mit noch nicht gelöschtem Login oder ein Drittanbieter-CI-Job, dem ein eigenes Repository zugewiesen wurde. Direkter Netzwerk-Zugriff auf den Gitea-Server ist nicht erforderlich, weil der Angriff über die reguläre HTTP-API erfolgt.
Was sollten Admins jetzt tun?
- Gitea-Version prüfen: Auf der eigenen Instanz die installierte Version mit der Liste der Gitea-Sicherheits-Releases vom 3. Juli 2026 abgleichen. Instanzen, die nicht auf dem aktuellen Patch-Stand sind, müssen kurzfristig aktualisiert werden.
- Actions-Status prüfen: In der Gitea-Administration prüfen, ob Actions aktiviert ist und welche Repositories Workflows ausführen. Bei deaktivierten Actions entfällt die Sofortmaßnahme, eine Aktualisierung der Instanz sollte trotzdem im regulären Wartungszyklus erfolgen.
- Logs auswerten: In den Gitea-Audit-Logs und Repository-Action-Logs der vergangenen 14 Tage nach ungewöhnlichen Artefakt-Downloads durch fremde Nutzer, abrupten Änderungen an Upload-Status und Workflow-Läufen außerhalb der regulären Zeitfenster suchen.
- Zugriffsrechte einschränken: Accounts ehemaliger Mitarbeiter und nicht mehr benötigter Drittanbieter-Integrationen deaktivieren, persönliche Access-Tokens rotieren und das Self-Registration-Feature in der Gitea-Konfiguration deaktivieren, falls es aktiv war.
- Lieferkette absichern: In den CI-Pipelines zusätzliche Prüfschritte einbauen, die Artefakt-Hashes gegen einen unabhängigen Signaturdienst verifizieren, sodass eine Manipulation des Upload-Status allein nicht ausreicht, um produktive Deployments zu beeinflussen.
- Backup und Restore testen: Vor dem eigentlichen Update-Vorgang ein vollständiges Backup der Gitea-Datenbank und der Artefakt-Speicherung anlegen, damit bei Problemen mit dem neuen Build ein definierter Restore-Punkt existiert.
Einordnung für Unternehmen
Gitea ist im KMU- und Selfhosting-Umfeld eine beliebte Alternative zu GitHub und GitLab, weil die Installation schlank ist und die Datenhoheit beim Betreiber bleibt. Mit wachsender Verbreitung steigt aber auch die Aufmerksamkeit professioneller Angreifer, und CI/CD-Pipelines sind ein lohnendes Ziel, weil eine Kompromittierung direkten Einfluss auf die ausgelieferte Software hat. CVE-2026-58426 erinnert daran, dass Selfhosting nicht nur Inbetriebnahme bedeutet, sondern einen verbindlichen Patch-Rhythmus erfordert, idealerweise mit automatisierten Tests in einer Staging-Instanz, bevor ein Update in die produktive Instanz ausgerollt wird. Wer Gitea betreibt und noch keinen Wartungsprozess etabliert hat, sollte diesen Vorfall als Weckruf nutzen, einen regelmäßigen Update- und Test-Zyklus einzurichten.
Passende Anleitungen auf S-EDV
- Cordyceps: Kritische CI/CD-Lücken gefährden 300+ GitHub-Repos ordnet die allgemeine Bedrohungslage in CI/CD-Pipelines ein und zeigt vergleichbare Vorfälle.
- WordPress-Sicherheit: Plugin-Risiken brauchen feste Update- und Prüfprozesse liefert ein übertragbares Muster für strukturierte Update- und Review-Prozesse in selbst gehosteten Setups.
- CISA KEV: Warum der Known Exploited Vulnerabilities Catalog für Admins Pflicht ist hilft bei der Frage, wie kritische Lücken in den eigenen Patch-Prozess einsortiert werden.
