Wer in den letzten vier Jahren eine private Container-Registry auf einer Gitea-Instanz betrieben hat, sollte heute keine ruhige Stunde mehr haben. Am 25. Mai 2026 hat das britische Security-Unternehmen Noscope die CVE-2026-27771 oeffentlich gemacht – und damit eine Schwachstelle in der weit verbreiteten Self-Hosted-Plattform Gitea, die schlicht unfassbar ist: Container-Images, die im UI als private markiert waren, liessen sich von jedem beliebigen Internetnutzer ohne Account, ohne Passwort und ohne Token einfach per docker pull herunterladen. Vier Jahre lang. In ueber 30 Laendern. In schaetzungsweise 30.000 Installationen.

Fuer den deutschen Mittelstand, der Gitea aus genau jenen Gruenden bevorzugt, die wir auf unserer Seite zur Informationssicherheit regelmaessig benennen – Datenhoheit, On-Premise-Kontrolle, kein Vendor-Lock-in – ist diese Meldung mehr als ein gewoehnlicher Patch-Day. Sie zwingt jede betroffene Organisation zu drei sehr unbequemen Schritten: patchen, drehen, beweisen. Wer das in den naechsten 72 Stunden nicht erledigt, geht davon aus, dass alle in den Images gelagerten Geheimnisse als oeffentlich gelten muessen.

Was die Luecke konkret tut

Gitea bringt seit Version 1.17 eine eingebaute Container-Registry mit, die OCI- und Docker-Images verwalten kann. Sie sitzt auf demselben Datenmodell wie die uebrigen Paket-Typen – Maven, npm, Composer, RubyGems – und teilt sich daher dieselbe Permission-Logik. Genau in dieser geteilten Logik liegt die Schwachstelle: Beim Abruf von Manifesten und Image-Blobs ueber die Endpunkte unter /v2/{owner}/{image}/... wurde die Sichtbarkeitseinstellung des Pakets nicht konsistent geprueft. Wer den Repository-Namen kannte oder erriet, konnte ueber den OCI-Standardpfad sowohl Manifest als auch alle referenzierten Layer abrufen – und damit das vollstaendige Image rekonstruieren.

Praktisch lief der Angriff in zwei trivialen Schritten ab: erstes GET auf /v2/orgname/imagename/manifests/latest liefert das Manifest mit den Layer-Digests, zweites GET auf /v2/orgname/imagename/blobs/sha256:... liefert jeden Layer. Beides ohne Authorization-Header. Wer den Tag-Namen nicht kannte, bekam ueber /v2/_catalog oder den Tag-List-Endpunkt zumindest brauchbare Hinweise auf vorhandene Repositories. In der Konsequenz reichten zwei curl-Befehle gegen eine bekannte Gitea-URL, um den kompletten Build-Artefaktbestand eines Unternehmens herunterzuladen.

Die kritische Konsequenz: Container-Images sind keine harmlosen Binaries. Sie tragen typischerweise Anwendungs-Source-Code in kompilierter oder interpretierter Form, eingebettete Konfigurationsdateien, Build-Time-Secrets, eingebrannte API-Keys, interne Service-Endpoints und in vielen Faellen auch TLS-Zertifikate und Datenbank-Passwoerter, die nie in den Container haetten gelangen duerfen. Wer ueber Jahre hinweg eine Pipeline betreibt, in der die .env nicht ueber Secrets-Mounts, sondern in den Image-Layern landet, hat mit dieser Luecke jede Compliance-Aussage zur Vertraulichkeit dieser Daten verloren.

Wer ist betroffen

Noscope nennt 30.000+ Deployments in mehr als 30 Laendern, mit den hoechsten Konzentrationen in China, den USA, Deutschland, Frankreich und Grossbritannien. Branchenseitig stehen Gesundheitswesen, Luft- und Raumfahrt, Einzelhandel und Internet-Service-Provider im Fokus. Fuer den deutschen Markt heisst das uebersetzt: Krankenhaeuser und MVZ-Verbuende mit eigener IT-Abteilung, Zulieferer im Luftfahrt-Cluster Hamburg/Bremen/Augsburg, mittelstaendische SaaS-Anbieter, regionale ISPs und nicht zuletzt jeder Maschinenbauer, der sich nach dem Microsoft- und GitHub-Konsolidierungsschock 2024 fuer eine selbst betriebene Git-Plattform entschieden hat.

Wichtig: Die Schwachstelle betrifft auch Forgejo, den community-gefuehrten Fork von Gitea, da dieser dieselbe Container-Registry-Implementierung uebernommen hat. Wer also nach 2023 von Gitea auf Forgejo gewechselt ist, in der Annahme, das Sicherheitsmodell sei dort frischer kuratiert, ist trotzdem im Risiko-Set. Bis zum gepatchten Forgejo-Release gilt derselbe Workaround wie bei Gitea.

Welcher Patch hilft – und welcher Workaround

Der Gitea-Maintainerkreis hat den Fix bereits am 20. Mai 2026 als Teil von Gitea 1.26.2 ausgeliefert, fuenf Tage vor der Veroeffentlichung des Advisories. Im Patch-Changelog liest sich der Eintrag harmlos: „Add label for private and internal package and fix composor package source permission check." Das ist – mit Verlaub – Understatement: Der Permission-Check fuer Composer-Pakete deckt im selben Codepfad auch Container-Manifeste ab, und das UI-Label fuer privat/intern existiert bis dahin schlicht nicht. Wer die Release-Notes nur ueberflogen hatte, koennte den Fix als kosmetisch fehlinterpretiert haben.

Fuer Organisationen, die nicht in 24 Stunden updaten koennen, hat Noscope einen pragmatischen Workaround dokumentiert: In der app.ini die Option [service].REQUIRE_SIGNIN_VIEW=true setzen und Gitea neu starten. Damit wird die gesamte Lese-Schnittstelle hinter Authentication gezogen – auch der oeffentliche Teil. Das brueskiert internetweite Pull-Statistiken und Mirroring-Strukturen, aber es schliesst den anonymen Zugriff sofort. Auf produktiven Multi-Tenant-Instanzen ist das eine bewusste Abwaegung; auf reinen On-Prem-Setups in einem geschlossenen Unternehmensnetz ist es ohne Reue umsetzbar.

Discovery durch eine KI – die kleine, hoechst unangenehme Ironie

Noscope schreibt in seinem Disclosure-Bericht offen, dass die Schwachstelle nicht von einem menschlichen Researcher gefunden wurde, sondern durch einen autonomen Penetration-Testing-Agenten, den das Unternehmen seit 2025 entwickelt. Der Agent durchforstet OCI-konforme Registries und prueft systematisch, ob die deklarierte Sichtbarkeit dem tatsaechlichen Verhalten entspricht. Diese Anekdote ist mehr als ein Marketing-Schnoersel: Sie ist ein Indikator dafuer, dass die Asymmetrie der Vulnerability-Discovery sich verschiebt. Auch Angreifer betreiben mittlerweile vergleichbare Agenten – Google Threat Intelligence hat am 11. Mai 2026 den ersten dokumentierten AI-built Zero-Day in freier Wildbahn beschrieben. Lesen Sie dazu unsere Hintergrundanalyse zu KI-Strategie und Integration im Unternehmen.

Heisst praktisch: Wer heute eine alte Schwachstelle in einer Open-Source-Komponente hat und glaubt, sie sei „eh nie gefunden worden", arbeitet mit einem Glaubenssatz aus 2019. 2026 ist die Frage nicht mehr ob, sondern wann ein automatisierter Scan durchlaeuft.

Sofortmassnahmen-Checkliste fuer den IT-Verantwortlichen

1. Inventur in 60 Minuten. Identifizieren Sie jede Gitea- oder Forgejo-Instanz im Unternehmen. Schatten-IT inklusive – das R&D-Team haelt erfahrungsgemaess gern eine Instanz auf einem Hetzner-Server, von der die Zentral-IT nichts weiss. Pruefen Sie /api/v1/version auf jedem verdaechtigen Host.

2. Patch oder Workaround. Update auf Gitea 1.26.2 bzw. den entsprechenden Forgejo-Release. Wenn das nicht binnen 24 Stunden moeglich ist, sofort REQUIRE_SIGNIN_VIEW=true setzen und mit docker pull anonymous@instance/... verifizieren, dass anonymer Zugriff geblockt ist.

3. Logs auswerten. Loggt Ihre Gitea-Instanz Pull-Requests, dann ziehen Sie sich die letzten 90 Tage access_log oder Reverse-Proxy-Logs und filtern Sie auf GET /v2/.../manifests/ und GET /v2/.../blobs/ ohne Authorization-Header. Treffer von unbekannten IPs oder Tor-Exit-Nodes sind Indikatoren fuer einen erfolgten Zugriff. Pruefen Sie sie auf User-Agent-Strings wie containerd, docker, skopeo oder oras.

4. Secret-Rotation in der Annahme einer Kompromittierung. Wer die Logs nicht aussagekraeftig auswerten kann, muss davon ausgehen, dass jedes Geheimnis, das in den letzten vier Jahren in einem Container-Image-Layer lag, oeffentlich ist. Das bedeutet: Datenbank-Passwoerter rotieren, API-Keys widerrufen, OAuth-Client-Secrets neu ausstellen, TLS-Zertifikate reissen und neu ausstellen lassen, eingebrannte SSH-Schluessel revoken. Wer SOPS, sealed-secrets oder External Secrets Operators einsetzt, kommt schneller durch diese Rotation. Wer noch .env-Dateien in die Layer kopiert, hat jetzt ein 14-Tage-Projekt vor sich.

5. Build-Pipeline absichern. Auch ohne diese spezielle CVE gilt: Build-Time-Secrets gehoeren nicht in Image-Layer, sondern in BuildKit---secret-Mounts, in Sealed Secrets oder in ein dediziertes Secrets-Management wie HashiCorp Vault oder Doppler. Wir empfehlen die Migration im Rahmen der naechsten Sprint-Planung – Details und Begleitung dazu finden Sie unter unseren Leistungen.

6. Image-Audit. Mit Werkzeugen wie trufflehog, gitleaks oder trivy secret alle in der Registry vorhandenen Images auf eingebettete Secrets scannen. Treffer dokumentieren, bewerten, rotieren – und die entsprechende Image-Version vollstaendig aus der Registry und aus Caches entfernen.

7. Netzwerk-Segmentierung pruefen. Eine Gitea-Instanz, die per Reverse Proxy direkt aus dem Internet erreichbar ist, sollte 2026 ohnehin ueberprueft werden. Wer keine externen Mitarbeiter braucht, sollte sie hinter ein VPN oder eine ZTNA-Loesung stellen. Wer externe Pulls braucht, sollte zumindest Rate-Limiting und IP-Allow-Listing fuer kritische Repositories umsetzen.

8. Meldung an Aufsichtsbehoerden pruefen. Sind in den geleakten Images personenbezogene Daten enthalten – etwa Test-Datenbanken mit Echtdaten? Dann liegt ein meldepflichtiges Datenschutz-Ereignis nach Art. 33 DSGVO vor. Sind Sie NIS2-betroffen und die Images enthalten Material kritischer Dienste, gilt die 24-Stunden-Erstmeldung an das BSI. Mehr Details zur Pflichtkette finden Sie unter Compliance-Software.

Strategische Konsequenz: Self-Hosting ist kein Sicherheits-Joker mehr

Wer Gitea statt GitHub gewaehlt hat, hat das in der Regel mit Hinweis auf Souveraenitaet und Datenkontrolle begruendet. Diese Argumentation bleibt richtig – sie verlangt aber, dass die Self-Hosted-Plattform mit derselben Patch-Disziplin und derselben Logging-Tiefe betrieben wird wie ein SaaS-Produkt. CVE-2026-27771 ist ein schmerzhafter Reminder, dass Open-Source-Plattformen nicht automatisch sicherer sind, sondern denselben menschlichen Pruefdruck brauchen wie geschlossene Systeme. Die Tatsache, dass diese Luecke vier Jahre lang unentdeckt blieb, zeigt, dass das Code-Auditing-Modell der Open-Source-Community auch 2026 weiterhin systematische Luecken hat – und dass automatisierte Pruefagenten von Angreifern wie Verteidigern diese Luecken zukuenftig deutlich schneller adressieren werden.

Fuer Geschaeftsfuehrungen heisst das: Die Frage „Welche selbstbetriebenen Plattformen haben Sie?" muss heute auf jeder Vorstandsagenda stehen, und sie muss begleitet werden von der Folgefrage „Wer ist verantwortlich, dass sie binnen 48 Stunden gepatcht werden, wenn ein Advisory erscheint?". Wenn diese Verantwortung nicht klar zugeordnet ist, ist sie de facto bei niemandem.

Wer Hilfe bei der Inventur, bei der Patch-Operation oder beim anschliessenden Audit braucht, findet bei pleXtec ein Team, das genau diese Operationen in den letzten zwoelf Monaten Dutzende Male durchgespielt hat. Sprechen Sie uns an: /kontakt.