GitLab: Kritische Path-Traversal-Lücke CVE-2026-85706 mit CVSS 10.0

GitLab hat am 10. und 11. September 2026 ein außerplanmäßiges Sicherheitsupdate veröffentlicht, das eine Schwachstelle mit dem maximalen CVSS-Wert 10.0 schließt. CVE-2026-85706 ist ein Path Traversal in der Repository-Commits-API. Ein Angreifer kann ohne jede Anmeldung beliebige Dateien vom Dateisystem des GitLab-Servers auslesen, also auch Konfigurationsdateien, hinterlegte Zugangsdaten und Secrets. Handeln müssen heute alle Betreiber einer selbst gehosteten GitLab-Instanz (self-managed, Community Edition wie Enterprise Edition) ab Version 18.7.

Nicht handeln müssen Kunden, die ihre Projekte auf GitLab.com betreiben: Die SaaS-Plattform läuft nach Herstellerangaben bereits gepatcht. Auch GitLab-Dedicated-Kunden müssen nichts tun, GitLab spielt die Patches dort selbst ein. Wer dagegen eine eigene Instanz im Rechenzentrum, in einer VM oder als Container betreibt, sollte die Version noch heute prüfen. Die Sicherheitsfirma watchTowr meldete bereits einen Tag nach der Veröffentlichung erste Probes im Internet, also gezielte Scans nach verwundbaren Servern.

Was ist passiert?

Die Schwachstelle steckt in der Repository-Commits-API von GitLab. Dort wird ein vom Client übergebener Dateipfad nicht korrekt auf das Projektverzeichnis eingeschränkt. GitLab spricht von einer fehlerhaften Pfadeinschränkung, im englischen Advisory als improper path confinement bezeichnet. Zusätzlich fehlt an dieser Stelle eine Authentifizierungsprüfung. Beide Fehler zusammen ergeben den Höchstwert: Der Angriff ist über das Netzwerk möglich, benötigt keine Anmeldung, keine Nutzerinteraktion und keine besonderen Vorbedingungen.

Gemeldet wurde die Lücke von einem Sicherheitsforscher mit dem Handle s3ntago über das HackerOne-Bug-Bounty-Programm von GitLab. Der Hersteller hat die Korrektur in drei parallel gepflegten Zweigen ausgeliefert, damit Betreiber nicht zwingend einen großen Versionssprung machen müssen.

Im selben Patch steckt eine zweite kritische Schwachstelle: CVE-2026-87719 mit CVSS 9.9 beschreibt eine unsichere Deserialisierung im GraphQL-Subscription-Serializer. Sie betrifft nur die Enterprise Edition und erlaubt authentifizierten Nutzern mit Zugriff auf den Duo-Chat, Zugangsdaten und Advanced-Search-Konfigurationen abzugreifen. Insgesamt behebt das Update 17 weitere Schwachstellen, darunter sechs hochriskante. Dazu zählen Remote Code Execution, Zugriff auf geschützte CI/CD-Variablen, Cross-Site-Scripting und Denial of Service.

Wer ist betroffen?

Betroffen sind GitLab Community Edition und Enterprise Edition ab Version 18.7. Die folgende Tabelle zeigt, welche Zweige verwundbar sind und auf welche Version Sie jeweils aktualisieren müssen.

Betroffener Versionszweig	Verwundbar	Gepatchte Version
GitLab CE/EE 18.7 bis 19.1	ab 18.7 vor 19.1.8	19.1.8
GitLab CE/EE 19.2	19.2 vor 19.2.6	19.2.6
GitLab CE/EE 19.3	19.3 vor 19.3.2	19.3.2
GitLab.com (SaaS)	nein, bereits gepatcht	kein Handlungsbedarf
GitLab Dedicated	wird vom Hersteller gepatcht	kein Handlungsbedarf

Praktisch heißt das: Jede selbst betriebene Instanz, die seit Ende 2025 auf 18.7 oder neuer aktualisiert wurde und seitdem kein Update mehr bekommen hat, ist mit hoher Wahrscheinlichkeit verwundbar. Typische Konstellationen in kleinen und mittleren Unternehmen:

• GitLab CE als Docker-Container auf einem eigenen Server oder einer NAS-Appliance.
• GitLab EE als virtuelle Maschine im eigenen Rechenzentrum oder beim Hoster.
• GitLab-Omnibus-Installation direkt auf einem Linux-Server.
• GitLab hinter einem Reverse Proxy, auch wenn die Instanz nur intern erreichbar ist.
• Entwicklungs- und Testinstanzen, die niemand mehr aktiv pflegt.

Besonders unangenehm sind vergessene Test- und Altinstanzen. Sie sind oft aus dem Internet erreichbar, laufen aber außerhalb des regulären Patch-Zyklus und enthalten trotzdem echte Zugangsdaten aus alten Projekten.

Wie kritisch ist das?

CVSS 10.0 ist der höchstmögliche Wert und wird selten vergeben. Die Kombination aus fehlender Authentifizierung und beliebigem Dateizugriff bedeutet, dass ein Angreifer ohne Konto und ohne Vorwissen an den Inhalt von Dateien kommt, die der GitLab-Prozess lesen darf. Dazu gehören in der Praxis Datenbank-Zugangsdaten, Secrets für CI/CD-Runner, Tokens für angebundene Dienste und Schlüsselmaterial. Der eigentliche Schaden entsteht meist nicht durch das Auslesen selbst, sondern durch die anschließende Weiterverwendung dieser Zugangsdaten.

Wichtig für die nüchterne Einordnung: Bestätigt sind bisher Probes, also Scans nach verwundbaren Systemen. Eine bestätigte Masseausnutzung gibt es nach derzeitigem Stand nicht. Jake Knott, Head of Threat Intelligence bei watchTowr, verweist allerdings darauf, dass dies innerhalb kurzer Zeit bereits die zweite kritische GitLab-Lücke ist. Die vorherige GraphQL-Code-Injection CVE-2026-19478 wurde nahezu sofort aktiv ausgenutzt. Diese Vorgeschichte macht die Annahme, man habe noch Wochen Zeit, unrealistisch.

Technisch handelt es sich um einen Datenabfluss, nicht um direkte Codeausführung. Wer daraus aber Zugangsdaten zieht, kann in einem zweiten Schritt sehr wohl zu Codeausführung in der CI/CD-Pipeline gelangen. Die Lücke gehört deshalb in dieselbe Dringlichkeitsklasse wie eine unauthentifizierte Remote Code Execution, auch wenn sie technisch nicht dasselbe ist.

Was sollten Admins jetzt tun?

Die Reihenfolge ist entscheidend. Erst prüfen, dann patchen, dann forensisch nachsehen, dann Zugangsdaten erneuern. Wer sofort Secrets rotiert, ohne vorher zu patchen, verteilt frische Zugangsdaten auf ein weiterhin verwundbares System.

1. Version feststellen. Die laufende Version steht in der Admin-Oberfläche unter Hilfe, alternativ liefert gitlab-rake gitlab:env:info auf einer Omnibus-Installation oder docker exec <container> gitlab-rake gitlab:env:info im Containerbetrieb die Angabe. Alles ab 18.7 und unterhalb der Fix-Versionen ist betroffen.
2. Patch einspielen. Ziel ist 19.3.2, 19.2.6 oder 19.1.8, je nach aktuellem Zweig. Ein Wechsel auf den passenden Patch-Level innerhalb des eigenen Zweigs ist der schnellste Weg und vermeidet große Migrationsschritte. Vor dem Update ein Backup der Instanz und der Datenbank anlegen.
3. Erreichbarkeit prüfen. Solange das Update aussteht, die Instanz nach Möglichkeit nicht aus dem Internet erreichbar lassen. Eine Einschränkung per Firewall, VPN oder Reverse-Proxy-Regel ist eine Zwischenlösung, kein Ersatz für den Patch.
4. Logs auf Angriffsversuche durchsuchen. watchTowr empfiehlt, die Logs nach HTTP-POST-Requests auf /api/v4/projects/{id}/repository/commits/ mit file.path-Parametern zu durchsuchen. Treffer sind ein starker Hinweis auf einen Ausnutzungsversuch.
5. Secrets rotieren, wenn Treffer vorliegen. Betroffen sind Datenbankpasswörter, CI/CD-Variablen, Runner-Registrierungstoken, Deploy-Keys, Personal Access Tokens und alle in der Konfiguration hinterlegten Zugangsdaten für Drittsysteme.
6. Vergessene Instanzen inventarisieren. Test-, Demo- und Altinstanzen in die Prüfung einbeziehen. Wer sie nicht mehr braucht, sollte sie abschalten statt sie zu patchen.
7. Enterprise Edition zusätzlich prüfen. Wer Duo-Chat im Einsatz hat, ist auch von CVE-2026-87719 betroffen und sollte den Nutzerkreis mit Duo-Zugriff nachvollziehen.

Einordnung für Unternehmen

GitLab ist in vielen kleinen Unternehmen mehr als eine Codeverwaltung. Die Instanz hält oft auch die Deployment-Pipelines, die Zugangsdaten zu Produktivsystemen und die Container-Registry. Ein Datenabfluss auf dieser Ebene betrifft damit nicht nur die Entwicklungsabteilung, sondern die gesamte Betriebsumgebung. Das ist der Grund, warum diese Lücke auch ohne bestätigte Masseausnutzung ein Fall für ein kurzfristiges Wartungsfenster ist und nicht für den nächsten regulären Patch-Termin.

Für die Dokumentation lohnt sich ein kurzer schriftlicher Vermerk: wann die Version geprüft wurde, welcher Patch-Stand eingespielt wurde, ob die Logprüfung Treffer ergab und welche Zugangsdaten erneuert wurden. Kommt es später zu einem Vorfall, ist das der Nachweis, dass zeitnah reagiert wurde.

Wer GitLab betreibt, sollte außerdem die Update-Praxis grundsätzlich prüfen. Zwei kritische Lücken in kurzer Folge zeigen, dass ein Zyklus von mehreren Monaten für diese Software nicht ausreicht. Eine Benachrichtigung über neue GitLab-Patch-Releases und ein fest eingeplantes monatliches Wartungsfenster kosten wenig und verkürzen das Zeitfenster für Angreifer deutlich.

Passende Anleitungen auf S-EDV

• GitLab schließt kritische Code-Injection-Lücke CVE-2026-19478: die vorherige kritische GitLab-Lücke, die kurz nach der Veröffentlichung aktiv ausgenutzt wurde.
• GitLab CE mit Docker als DevOps-Plattform betreiben: Installation, Konfiguration und Update-Vorgehen für die Container-Variante.
• Docker-Images mit Trivy auf Schwachstellen scannen: wie Sie verwundbare Versionsstände in Ihren Containern systematisch finden.

Quellen

• BleepingComputer: GitLab urges users to patch max severity path traversal flaw (11.09.2026)
• SecurityWeek: GitLab Vulnerability Exploited One Day After Disclosure (11.09.2026)
• GitLab: Patch Release 19.3.2, 19.2.6 und 19.1.8 (10.09.2026)