GitLab-Lücke liest Serverdateien ohne Login – Self-Hosting muss patchen
Seit dem 17. September 2026 wird aktive Ausnutzung einer kritischen Lücke in GitLab CE und EE gemeldet. Die Warnung der Cyber Security Agency of Singapore nennt einen öffentlich verfügbaren Proof of Concept: Unter bestimmten Bedingungen können nicht angemeldete Angreifer über die Repository Commits API beliebige Dateien lesen, auf die der GitLab-Server zugreifen kann.
Betroffen sind selbstverwaltete Installationen ab Version 18.7 bis zu den korrigierten Ständen 19.1.8, 19.2.6 und 19.3.2. GitLabs technische Einordnung begrenzt die Reaktion auf GitLab Self-Managed; GitLab.com und GitLab Dedicated sind bereits gepatcht. Sie erklärt zugleich, warum ein erkannter Dateizugriff nicht automatisch beweist, dass Dateiinhalte an den Angreifer übertragen wurden.
Welche selbstverwalteten Instanzen betroffen sind
Die Schwachstelle entsteht durch fehlende Authentifizierungsprüfungen und eine unzureichende Begrenzung von Dateipfaden in der Repository Commits API. Ein manipulierter Parameter kann aus dem vorgesehenen Upload-Bereich heraus auf einen beliebigen serverseitigen Pfad verweisen. Für den Zugriff ist weder ein Benutzerkonto noch eine vorherige Anmeldung erforderlich; die Bewertung liegt bei CVSS 10,0.
Verwundbar sind GitLab CE und EE von 18.7 bis einschließlich 19.1.7, von 19.2.0 bis 19.2.5 sowie von 19.3.0 bis 19.3.1. Die Korrektur betrifft alle Bereitstellungsarten, sofern keine abweichende Einschränkung genannt ist – damit auch Installationen über Linux-Pakete, aus dem Quellcode oder per Helm.
Eine Prüfung nur der Haupt- oder Nebenversion reicht deshalb nicht. So gehört 19.3.1 zum verwundbaren Bereich, während 19.3.2 die Lücke schließt. Betreiber älterer Installationen sollten auf einen unterstützten, vollständig aktualisierten Versionszweig wechseln und dabei die vorgesehenen Upgrade-Pfade beachten.
Patchen und Protokolle vor dem Neustart sichern
Das Update sollte wegen der gemeldeten aktiven Ausnutzung als Incident-Reaktion behandelt werden. Vor einem Upgrade oder Neustart müssen jedoch die vorhandenen Rails-API-, Workhorse- und gegebenenfalls NGINX-Protokolle einschließlich rotierter Dateien gesichert werden: Ein Neustart kann den Workhorse-Log rotieren und damit Einträge überschreiben, die für die spätere Untersuchung benötigt werden.
- Installierte Version und Betriebsmodell feststellen; Kundenmaßnahmen sind nur bei GitLab Self-Managed erforderlich.
- API-, Workhorse- und gegebenenfalls NGINX-Protokolle vor dem Neustart beweissicher kopieren und wie geheimnishaltige Daten schützen.
- Auf den korrigierten Stand des gewählten Versionszweigs oder eine neuere unterstützte Version aktualisieren.
- Verdächtige Requests untersuchen und nur bei belegter oder nicht zuverlässig auszuschließender Offenlegung die betroffenen Zugangsdaten, Token oder Schlüssel gezielt ersetzen.
Der Patch beseitigt den verwundbaren Codepfad, beantwortet aber nicht rückwirkend, ob die Instanz bereits angegriffen wurde. Versionsprüfung und forensische Auswertung bleiben deshalb getrennte Aufgaben. Auch auf einem inzwischen aktualisierten System können die gesicherten Protokolle Zugriffe aus der Zeit vor dem Patch dokumentieren.
Drei Erkennungsregeln suchen nach Angriffsversuchen
Das GitLab-Patchbulletin vom 10. September 2026 führt drei veröffentlichte Threat Detections auf und beschreibt außerdem die Upgrade-Auswirkungen:
- GitLab LFI attempt reading gitlab.yml: markiert Versuche, die GitLab-Konfigurationsdatei gitlab.yml zu lesen.
- GitLab LFI via metadata.path parameter: sucht nach Path-Traversal-Versuchen über metadata.path.
- GitLab LFI file path attempt: erkennt entsprechende Zugriffe über einen manipulierten Dateipfad.
Ein Treffer belegt zunächst einen Angriffsversuch, nicht zwangsläufig eine erfolgreiche Offenlegung. Für die Einordnung müssen die Werte von file.path und metadata.path nach der Prozentdekodierung und Auflösung von „..“-Segmenten einzeln geprüft werden. Eine Filterung nur nach der sichtbaren API-Route kann Umgehungsversuche übersehen, weil sowohl Teile des Pfads als auch Parameternamen kodiert sein können.
Dateizugriff und tatsächliche Offenlegung trennen
Die Lücke veranlasst den Server, die angegebene Datei zu öffnen. Inhalte gelangen jedoch nur dann in die Antwort, wenn ihre Verarbeitung als Formulardaten an einer ungültigen Prozentkodierung scheitert und die Fehlermeldung das betroffene Fragment enthält. Deshalb reichen weder der HTTP-Status noch die Größe der anvisierten Datei aus, um einen Abfluss zu bestätigen oder auszuschließen.
Zur Prüfung werden verdächtige Einträge aus api_json.log über ihre correlation_id mit dem Workhorse-Zugriffslog verbunden. Das Feld written_bytes zeigt die tatsächlich an den Client gesendete Antwortgröße; api_error kann das offengelegte Dateifragment im Klartext enthalten. Die Auswertung muss den für die jeweilige Instanz ermittelten Fehler-Basiswert sowie mögliche Veränderungen durch Reverse Proxies oder Kompression berücksichtigen.
Fehlt ein benötigter Logeintrag, wurde er abgeschnitten oder durch Rotation entfernt, lässt sich aus dieser Methode keine Entwarnung ableiten. Auch die Beweiskopien selbst sind sensibel: Ein protokollierter Parserfehler kann Zugangsdaten oder andere Geheimnisse aus der gelesenen Datei enthalten.
Single-Node-Systeme müssen Ausfallzeit einplanen
Die Sicherheitsversionen enthalten Datenbankmigrationen. Bei einer Single-Node-Instanz entsteht während des Upgrades eine Unterbrechung, weil die Migrationen abgeschlossen sein müssen, bevor GitLab wieder starten kann. Das Wartungsfenster sollte daher die Protokollsicherung, das Upgrade und die anschließende Funktionskontrolle umfassen, ohne das Update wegen der laufenden Angriffsaktivität unnötig aufzuschieben.
Mehrknoten-Installationen können den Patch bei korrekt umgesetztem Zero-Downtime-Verfahren ohne Unterbrechung einspielen. Für Version 19.3.2 kommen Post-Deploy-Migrationen hinzu, die nach dem eigentlichen Upgrade weiterlaufen können und bei der Kapazitätsplanung berücksichtigt werden müssen.
Was nach dem Update offenbleibt
Die verfügbaren Patches schließen den bekannten Angriffsweg, und für Self-Managed-Instanzen stehen konkrete Regeln zur Suche nach verdächtigen Requests bereit. Offen bleibt jeweils lokal, ob eine verwundbare Installation tatsächlich angesprochen wurde und ob dabei Dateifragmente an einen Client gelangten. Diese Fragen lassen sich nur anhand ausreichend vollständig erhaltener API- und Workhorse-Protokolle belastbar beantworten.
Lesen Sie auch:
Newsletter abonnieren
Erhalten Sie die neuesten Nachrichten zu Web3, KI und Krypto direkt in Ihren Posteingang.