Selbst gehostete Infrastruktur gilt in der DevOps-Welt als der Königsweg zur Datenhoheit. Wer Plattformen wie Gitea im eigenen Rechenzentrum oder auf privaten Servern betreibt, vertraut darauf, dass Zugriffsrechte sauber durchgesetzt werden. Eine nun aufgedeckte Schwachstelle zeigt jedoch eindrucksvoll, wie trügerisch dieses Sicherheitsgefühl sein kann.
Sicherheitsforscher der britischen Firma Noscope haben eine kritische Lücke in Gitea offengelegt, die es Remote-Angreifern ermöglicht, als „privat“ markierte Container-Images ohne jegliche Authentifizierung herunterzuladen. Kein Account, kein Passwort, kein Token – die Images waren für jeden im Internet frei zugänglich, der den richtigen Pfad kannte.
Vier Jahre im Verborgenen
Die Schwachstelle, die unter der Kennung CVE-2026-27771 geführt wird, betrifft alle Gitea-Versionen vor 1.26.2. Das vielleicht erschreckendste Detail an dieser Geschichte: Der Fehler blieb fast vier Jahre lang unentdeckt. In dieser Zeit vertrauten tausende Organisationen darauf, dass das Setzen des Häkchens „Private“ im Container-Repository den gewünschten Schutzeffekt hat.
„Die private Kennzeichnung auf einem Container-Repository bot nicht den Schutz, den Betreiber vernünftigerweise erwarten durften“, stellen die Forscher von Noscope fest. Die Container-Registry von Gitea interpretierte die Zugriffsrechte bei Pull-Anfragen schlichtweg falsch und behandelte private Images so, als wären sie öffentlich.
Massive Auswirkungen in kritischen Sektoren
Die Ausmaße der Sicherheitslücke sind beträchtlich. Noscope schätzt, dass weltweit mehr als 30.000 Gitea-Deployments in über 30 Ländern von dem Fehler betroffen sind oder waren. Schwerpunkte der Exposition liegen in China, den USA, Deutschland, Frankreich und Großbritannien.
Besonders brisant: Zu den betroffenen Organisationen gehören Healthcare-Provider, Luft- und Raumfahrtunternehmen, Einzelhandelsinfrastrukturen sowie Internet Service Provider. Bei diesen Branchen können geleakte Container-Images weitreichende Konsequenzen haben. Oft enthalten Images hartcodierte Secrets, Zugangsdaten zu Datenbanken oder proprietäre Geschäftslogik. Ein Angreifer, der solche Images pullt, erhält damit potenziell den Schlüssel zur weiteren Infrastruktur.
Das Fork-Problem in der Open-Source-Welt
Die Sicherheitslücke beschränkt sich nicht auf das Gitea-Hauptprojekt. Da der Code frei verfügbar ist, existieren diverse Forks. Noscope warnt ausdrücklich, dass jeder Fork von Gitea als potenziell anfällig betrachtet werden muss, bis die jeweiligen Maintainer das Gegenteil bestätigen. Ein prominentes Opfer ist Forgejo, der Community-Fork von Gitea, der nach den Lizenzstreitigkeiten der letzten Jahre an Bedeutung gewonnen hat. Auch Forgejo ist von der Schwachstelle betroffen.
Dies unterstreicht ein strukturelles Problem im Open-Source-Ökosystem: Sicherheitslücken pflanzen sich nahtlos in Forks fort. Wer aus politischen oder lizenzrechtlichen Gründen zu einem Fork wechselt, übernimmt damit auch den technischen Ballast – inklusive unentdeckter Bugs.
Journalistische Einordnung: Wenn UI und Implementierung auseinanderklaffen
Der Vorfall ist ein klassisches Beispiel für die Diskrepanz zwischen Benutzererwartung und technischer Implementierung. In modernen DevOps-Tools verlässt sich das Personal stark auf die grafische Oberfläche. Wenn ein Schalter „Private“ heißt, wird davon ausgegangen, dass das System im Hintergrund die entsprechenden Access-Control-Listen (ACLs) setzt. Dass dies bei der Gitea Container Registry jahrelang nicht der Fall war, offenbart eklatante Mängel im internen Testing und im Security-Review neuer Features.
Für die betroffenen Unternehmen ist dies ein Weckruf. Selbsthosting bedeutet nicht automatisch mehr Sicherheit, wenn die eigene IT-Abteilung nicht in der Lage ist, den Code der genutzten Tools zu auditieren oder zumindest kritische Patches zeitnah einzuspielen. Die Tatsache, dass der Fehler vier Jahre unentdeckt blieb, zeigt, wie selten in vielen Firmen der tatsächliche Datenfluss von eigenen Registries überprüft wird. Ein simples Monitoring, das ungewöhnliche Download-Volumina von angeblich privaten Repositories alarmiert hätte, fehlte offenbar vielerorts.
Was Betroffene jetzt tun müssen
Gitea-Nutzer und Administratoren müssen umgehend handeln:
- Update: Ein Update auf Gitea Version 1.26.2 schließt die Lücke. (Hinweis: In der Originalquelle wurde fälschlicherweise von Version 1.6.2 gesprochen, was aufgrund des Alters und der Versionshistorie ein offensichtlicher Tippfehler für 1.26.2 ist).
- Workaround: Wer nicht sofort patchen kann, sollte in der Gitea-Konfiguration den Wert
[service].REQUIRE_SIGNIN_VIEW=truesetzen. Das erzwingt eine Anmeldung auch für Lesezugriffe. Der Nachteil: Auch explizit öffentliche Container-Images sind dann nur noch für angemeldete Nutzer erreichbar, was den Workflow in offenen Projekten stören kann. - Audit: Unabhängig vom Patch sollten Betreiber prüfen, ob in den letzten Jahren ungewöhnliche Pulls von privaten Images stattfanden. Enthaltene Secrets sollten als kompromittiert betrachtet und umgehend rotiert werden.
Die Lücke CVE-2026-27771 mahnt zur Vorsicht: Wer die Verantwortung für seine Infrastruktur übernimmt, muss sie auch aktiv wahrnehmen. Vertrauen ist gut, Kontrolle – gerade bei Zugriffsrechten – ist besser.
Quelle: The Hacker News
