GitLab CE/EE (CVE-2026-85706)

Am Donnerstag, dem 10. September 2026, veröffentlichte GitLab ein kritisches Patch-Release. Laut watchTowr suchten Angreifer schon am nächsten Morgen ab 06:00 UTC gezielt nach der Lücke, die damit geschlossen wurde. Wer GitLab selbst betreibt, hatte zwischen Advisory und ersten Versuchen also Stunden, nicht Wochen.

Was ist CVE-2026-85706

GitLab beschreibt es so: Unter bestimmten Bedingungen konnte ein nicht authentifizierter Nutzer beliebige Dateien vom GitLab-Server lesen, weil die Repository Commits API Pfade nicht ausreichend begrenzte und keine Authentifizierung durchsetzte. Es versagten also zwei Prüfungen auf einmal. Die API prüfte nicht, wer fragte, und sie hielt den angefragten Pfad nicht dort, wo er hingehörte. Zusammen ergibt das einen Path Traversal, der jedem offensteht, der den Server erreicht.

GitLab bewertet die Lücke nach CVSS v3.1 mit 10.0. Stand 1. Oktober 2026 führt die NVD die Bewertung von GitLab und hat keine eigene veröffentlicht. Betroffen sind GitLab CE und EE ab 18.7 bis zu den gepatchten Versionen. GitLab.com und GitLab Dedicated sind laut GitLab bereits abgesichert.

Was die Angreifer taten

watchTowr sah die ersten Sondierungen in seinem Honeypot-Netzwerk ab 06:00 UTC am 11. September 2026, und die US-Behörde CISA nahm die Lücke noch am selben Tag in ihren Katalog aktiv ausgenutzter Schwachstellen (KEV) auf. In einem Update gegenüber The Hacker News berichtete watchTowr, dass die Angreifer vom Sondieren zur erfolgreichen Ausnutzung übergegangen waren: Sie zogen Konfigurationsdateien mit Secrets ab, dazu die SSH-Konfiguration des Systems. Laut watchTowr kann ein Angreifer mit dieser Kombination Passwörter extrahieren und sich unter den richtigen Bedingungen am Host selbst anmelden.

Das war ein N-Day, kein Zero-Day: Erst kam der Patch, dann kamen die Angriffe. Das niederländische NCSC warnte am 12. September, dass die Lücke aktiv ausgenutzt werde und öffentlicher Exploit-Code verfügbar sei. Das BSI folgte am 14. September mit einem IT-Sicherheitshinweis. Stand 1. Oktober 2026 hat keine Behörde und kein Sicherheitsanbieter öffentlich einen Akteur hinter den Angriffen benannt.

Warum ein Dateizugriff bei GitLab so schwer wiegt

Auf einem gewöhnlichen Webserver bringt das Lesen einer Datei genau das: eine Datei. Auf einem GitLab-Server liegen der Quellcode, die Pipelines, die ihn bauen und ausrollen, und die Zugangsdaten, mit denen diese Pipelines arbeiten. watchTowr formuliert es deutlich: Zugriff auf GitLab verschafft einem Angreifer Quellcode, CI/CD-Secrets, Zugangsdaten und die Möglichkeit, Code in Build-Pipelines einzuschleusen und damit alles Nachgelagerte zu vergiften. Das NCSC warnt, dass die erbeuteten Daten den Zugang zu Quellcode, Entwicklungsumgebungen oder anderen angebundenen Systemen öffnen können.

Damit geht es um mehr als das Auslesen von Dateien: Es ist ein Lieferkettenrisiko. Und wie bei CVE-2018-13379 überdauert der Schaden den Patch: Ein Token oder Passwort, das im September gelesen wurde, funktioniert so lange, bis es jemand austauscht.

Was jetzt zu tun ist

• Aktualisieren Sie selbstverwaltetes GitLab auf 19.3.2, 19.2.6 oder 19.1.8, auf älteren Zweigen auf 19.0.9 oder 18.11.12. Laut Rapid7 enthalten die Patch-Releases Datenbankmigrationen, planen Sie bei Single-Node-Installationen also Ausfallzeit ein.
• Hing die Instanz nach dem 10. September 2026 ungepatcht am Internet, gehen Sie davon aus, dass Dateien gelesen wurden. Tauschen Sie die Passwörter und Schlüssel aus der GitLab-Konfiguration, die CI/CD-Variablen und Tokens, mit denen Ihre Pipelines ausrollen, sowie die SSH-Zugangsdaten des Hosts aus.
• Durchsuchen Sie Ihre Logs nach POST-Anfragen an /api/v4/projects/{id}/repository/commits/ mit file.path-Parametern, dem Muster, nach dem watchTowr zu suchen empfiehlt. Rapid7 rät, auch nach dem Update nach Spuren einer Kompromittierung zu suchen.
• Stellen Sie GitLab nicht ohne Grund ins offene Internet, prüfen Sie, ob öffentliche Projekte überhaupt nötig sind, und nehmen Sie die Plattform in den Scope Ihres Penetrationstests auf.