Gitea Registry-Bug gibt private Images seit vier Jahren preis

Wer jemals einen selbst gehosteten Git-Server betrieben hat, kennt den Kompromiss: Man tauscht eine verwaltete SaaS-Rechnung gegen eine Ops-Oberfläche, die man nun um 3 Uhr morgens selbst verantwortet. CVE-2026-27771 ist genau die Art von Bug, der diesen Kompromiss teuer erscheinen lässt. Ein Logikfehler in Giteas eingebautem Container-Registry hat private OCI-Images seit fast vier Jahren still und heimlich an nicht authentifizierte Aufrufer ausgeliefert, und rund 31.750 internetfähige Instanzen waren noch exponiert, als das Advisory veröffentlicht wurde.

Wichtige Details

Die Schwachstelle, verfolgt als CVE-2026-27771 und am 28. Mai 2026 offengelegt, ist ein Authentication-Bypass in der Zugriffssteuerungslogik von Giteas Container-Registry. Wie Rescana berichtete, antwortet der Registry-Endpunkt auf Standard-Docker- und OCI-Pull-Anfragen von nicht authentifizierten Clients, selbst wenn das zugrundeliegende Repository als privat markiert ist. Kein Token. Kein Cookie. Kein Konto. Einfach ein Pull.

Der Umfang ist weitreichend. Jedes Gitea-Release von 1.13.0 bis einschließlich 1.26.1 ist betroffen, zusammen mit allen früheren Versionen, bei denen das Registry-Feature aktiviert ist. Das ist eine lange Liste von Versionen, die sich über rund vier Jahre erstreckt. Forgejo, der prominente Community-Fork, hat die verwundbare Codebasis geerbt und ist ebenfalls betroffen, andere Downstream-Forks sind wahrscheinlich in derselben Lage. On-Premises oder cloud-gehostet – das spielt keine Rolle. Der Bug liegt im Code-Pfad, nicht in der Deployment-Topologie.

NoScope Securitys autonomer Penetrationstest-Agent hat die Schwachstelle im April 2026 entdeckt und sie verantwortungsvoll an die Gitea-Maintainer gemeldet. Der Fix wurde in Gitea 1.26.2 ausgeliefert. Für Teams, die heute kein Binary ausrollen können, besteht der dokumentierte Workaround im Setzen von [service].REQUIRE_SIGNIN_VIEW=true in der Gitea-Konfiguration. Dieses Flag deaktiviert den anonymen Zugriff vollständig, auch auf legitim öffentliche Repositories und Images – es ist also ein grobes Instrument, aber es schließt die Tür.

Der Expositions-Fußabdruck ist der Teil, der Plattformverantwortliche beunruhigen sollte. Ungefähr 31.750 internetfähige Gitea-Deployments in mehr als 30 Ländern sind erreichbar, und über die Hälfte läuft auf großen Cloud-Plattformen. Betroffene Sektoren umfassen Gesundheitswesen, Luft- und Raumfahrt, Einzelhandel, ISPs und Enterprise-Software-Anbieter. Zum Zeitpunkt des Berichts gibt es keinen öffentlichen PoC und keine bestätigte Ausnutzung in freier Wildbahn, und keine APT-Gruppe wurde zugeordnet. Der Katalog bei MITRE ist der richtige Ort, um die Entwicklung des CVE-Eintrags zu verfolgen.

Warum das für Security-Teams wichtig ist

Ein Container-Image ist nicht nur ein binäres Blob. Es ist ein verpacktes Geständnis darüber, wie Ihr Service aufgebaut ist. Private Images enthalten routinemäßig Anwendungsquellcode, proprietäre Geschäftslogik, eingebettete API-Keys, Datenbank-Credentials und Infrastruktur-Konfigurationsdateien. Wer eines pullt, hat sich effektiv eine Woche lang über die Schulter eines Ingenieurs geschaut.

Das verändert die Kalkulation zu diesem Bug. Ein nicht authentifizierter Pull ist nur dann auffällig, wenn Sie den Registry-Zugriff auf der Ebene protokollieren, auf der nicht authentifizierte Anfragen sichtbar sind. Die meisten Teams, mit denen ich gearbeitet habe, protokollieren authentifizierte Aktivitäten gut und behandeln anonyme 200er als langweiliges CDN-Rauschen. Produktionsvorfälle, die ich erlebt habe, tauchen tendenziell Wochen später auf – wenn ein geleakter API-Key in einem Abrechnungsalarm eines anderen auftaucht, nicht wenn der Pull stattfindet.

Vier Jahre Exposition ist die andere hässliche Tatsache. Wenn Sie Gitea zwischen 1.13.0 und 1.26.1 mit aktivierter Registry und einem vom Internet (oder von einem kompromittierten internen Host) erreichbaren Port betrieben haben, können Sie nicht davon ausgehen, dass Ihre privaten Images privat geblieben sind. Sie müssen davon ausgehen, dass die Secrets in diesen Layern verbrannt sind. Rotieren Sie sie.

Meine Einschätzung: Der Patch ist die einfache Hälfte. Die schwierige Hälfte ist die Incident-Response-Haltung, die Sie nach dem Patchen einnehmen. Das bedeutet: Alle Images aufzählen, die während des Zeitfensters in der Registry lagen, diejenigen identifizieren, die Credentials oder Konfiguration einbetten, und diese Secrets unter der Annahme einer Kompromittierung rotieren. Behandeln Sie das wie ein Credential-Exposure-Event, nicht wie ein CVE-Ticket. Der CISA KEV-Katalog listet diesen noch nicht, und das ist kein Grund zur Entspannung. Es ist ein Grund, sich zu bewegen, bevor er es tut.

Eine scharfe Lektion: Wenn Ihre Registry Artefakte ausliefert, die Secrets enthalten, ist Ihre Registry ein Secret-Store – egal ob Sie es so geplant haben oder nicht.

Auswirkungen auf die Branche

Für iGaming- und Fintech-Unternehmen ist selbst gehostetes Git genau deshalb verbreitet, weil Regulierungsbehörden es nicht mögen, wenn der Quellcode auf dem S3-Bucket eines anderen liegt. Gitea und Forgejo sind beliebte Optionen, weil sie leichtgewichtig, schnell und ohne JVM auskommen. Der Kompromiss ist, dass man den Patch-Rhythmus selbst besitzt – und in einem 10-köpfigen Plattform-Team rutscht ein Gitea-Upgrade tendenziell hinter dem Kafka-Upgrade und dem Postgres-Minor-Bump jedes Quartal zurück.

Die Zahl 31.750 lohnt sich in operativen Begriffen zu interpretieren. Wenn auch nur ein Prozent dieser Deployments einen einzigen geleakten Cloud-Credential mit breitem IAM enthält, sind das Hunderte potenzieller nachgelagerter Vorfälle. Für einen mittelgroßen Betreiber läuft der Aufwand für einen einzigen rotierten Produktionsdatenbank-Credential – einschließlich der Bereitschaftsstunden, des gestaffelten Rollouts und des unvermeidlichen Post-Rotate-Connection-Sturms – leicht auf eine Woche Engineeringzeit hinaus. Multiplizieren Sie das mit jedem Secret, das Sie als verbrannt betrachten müssen, und Sie sehen echte Budgetbelastungen. In einem 10-köpfigen Plattform-Team ist das die Arbeit von zwei Ingenieuren für einen Sprint – weg für Aufräumarbeiten.

Die Cloud-gehostete Mehrheit der exponierten Instanzen sagt Ihnen auch etwas darüber, wie Teams Gitea behandeln. Es ist ein „Aufsetzen, Domain drauf zeigen, vergessen"-Service. Das ist genau das operative Muster, das mehrjährige Vulnerability-Fenster produziert. Die unbequeme Erkenntnis: Die meisten betroffenen Organisationen wissen wahrscheinlich nicht, dass ihr Registry-Feature jemals aktiviert war.

Für Ad-Tech- und DeFi-Unternehmen, die Gitea für interne Tooling betreiben, ist der Supply-Chain-Aspekt derjenige, den man im Auge behalten sollte. Ein geleaktes Image mit einem Build-Time-NPM-Token oder einem privaten Package-Registry-Credential ist ein perfekter Pivot für einen nachgelagerten Supply-Chain-Angriff. Die OWASP Top Ten hämmert seit Jahren auf Broken Access Control ein, und das aus gutem Grund: Diese Kategorie produziert weiterhin die Bugs mit dem größten Schadenspotenzial.

Was zu beobachten ist

Drei Signale sind in den nächsten Wochen wichtig. Erstens das Erscheinen eines öffentlichen PoC. Die Angriffsfläche ist Standard-Docker-Tooling gegen einen OCI-Endpunkt, also ist ein funktionierender Exploit ein kurzes Script. Sobald er auf GitHub ist, folgt opportunistisches Scanning innerhalb von Stunden. Honeypot-Betreiber werden es vor Verteidigern sehen.

Zweitens die CISA-KEV-Listung. Wenn aktive Ausnutzung bestätigt wird und sie in den KEV-Katalog aufgenommen wird, greifen bundesbehördliche Mandate, und eine Welle großer Unternehmen wird gezwungen sein, nach einem Kalender zu patchen. Das ist der Moment, in dem der ungepatchte lange Schwanz sichtbar schrumpft.

Drittens den Forgejo-Release-Rhythmus beobachten. Die Fork-Community bewegt sich nach eigenem Zeitplan, und nicht jeder Forgejo-Admin verfolgt die Gitea-CVE-Nummern upstream. Erwarten Sie eine zweite Welle der Exposition, während sich das Forgejo-spezifische Advisory verbreitet.

Meine Prognose: Innerhalb von 60 Tagen werden wir mindestens einen offengelegten Vorfall sehen, der auf einen geleakten Credential zurückzuführen ist, der aus einer Gitea-Registry gepullt wurde – selbst wenn der Registry-Pull selbst nicht die Schlagzeile ist. So tauchen diese Geschichten normalerweise auf: nachgelagert vom eigentlichen Bug.

Wichtige Erkenntnisse

• Gitea sofort auf 1.26.2 aktualisieren oder [service].REQUIRE_SIGNIN_VIEW=true als temporäre Sperre setzen. Forgejo und andere Forks benötigen ihre entsprechenden Patches.
• Dieses Ereignis als Credential-Exposure-Vorfall behandeln. Images aufzählen, die in der Registry lagen, eingebettete Secrets identifizieren und unter der Annahme einer Kompromittierung rotieren.
• Die Schwachstelle umfasst Gitea 1.13.0 bis 1.26.1, ungefähr vier Jahre an Releases. Ihr Expositionsfenster ist wahrscheinlich länger als Ihre Incident-Retention.
• Über 31.750 internetfähige Instanzen sind in mehr als 30 Ländern exponiert, davon mehr als die Hälfte auf großen Cloud-Plattformen. Gehen Sie davon aus, dass Ihre Kollegen diese Woche ebenfalls patchen.
• Container-Registries generell prüfen. Wenn das Pullen eines Images einem Angreifer funktionierende Credentials liefert, ist Ihre Registry Teil Ihrer Secrets-Oberfläche und muss entsprechend behandelt werden.