Über eine kritische GitLab-CVSS-10-Lücke können nicht authentifizierte Angreifer beliebige Dateien von einem GitLab-Server auslesen. Der Hersteller hat bereits Patches veröffentlicht, doch schon wenige Stunden nach Bekanntwerden wurden erste Ausnutzungsversuche in freier Wildbahn registriert. Betroffen sind sowohl die Community- als auch die Enterprise-Edition.
GitLab-CVSS-10-Lücke: Kritische Path-Traversal-Schwachstelle in der Repository-Commits-API
Die als CVE-2026-85706 gelistete Schwachstelle erreicht den maximalen CVSS-Score von 10.0. Sie ist eine Path-Traversal-Schwachstelle in der Repository-Commits-API, die es einem nicht authentifizierten Benutzer erlaubt, unter bestimmten Voraussetzungen beliebige Dateien vom GitLab-Server zu lesen. GitLab selbst nennt als Ursache eine unzureichende Pfadvalidierung und fehlende Authentifizierungsprüfung in der API.
Was ist CVE-2026-85706?
Die Schwachstelle erlaubt es externen Angreifern, über manipulierte Pfadangaben aus der vorgesehenen Verzeichnisgrenze auszubrechen. So lassen sich Log-Dateien und GitLab-spezifische Konfigurationsdateien auslesen, die Anmeldedaten, Secrets und weitere vertrauliche Informationen enthalten. Für die Ausnutzung genügt eine einzige Voraussetzung: Es muss mindestens ein öffentliches Projekt auf der betroffenen Instanz existieren.
Betroffene Versionen
Folgende Versionen von GitLab Community Edition (CE) und Enterprise Edition (EE) sind betroffen:
- alle Versionen ab 18.7 bis einschließlich 19.1.7
- alle Versionen ab 19.2 bis einschließlich 19.2.5
- alle Versionen ab 19.3 bis einschließlich 19.3.1
Damit sind alle selbst gehosteten Installationen gefährdet, die sich in einem dieser Versionsbereiche befinden und noch kein Sicherheitsupdate eingespielt haben.
Erste Angriffswellen: GitLab-CVSS-10-Lücke wird aktiv ausgenutzt
Sicherheitsforscher von watchTowr, einem auf die Identifikation exponierter Systeme spezialisierten Unternehmen, haben bereits am 11. September 2026 um 06:00 Uhr UTC aktive Sondierungen in freier Wildbahn registriert. Damit liegen zwischen der Veröffentlichung der Sicherheitsupdates und den ersten beobachteten Angriffsversuchen nur wenige Stunden.
Im Visier stehen dabei vor allem GitLab-Instanzen, die über das Internet erreichbar sind. Gelingt die Ausnutzung, können Angreifer Log-Dateien und GitLab-spezifische Konfigurationsdateien auslesen und auf diese Weise an Zugangsdaten, Secrets und weitere vertrauliche Informationen gelangen. Darüber hinaus bietet ein kompromittiertes GitLab die Möglichkeit, Schadcode in Build-Pipelines einzuschleusen und damit nachgelagerte Systeme zu infizieren oder zu manipulieren.
Innerhalb weniger Wochen ist dies bereits die zweite kritische GitLab-Sicherheitslücke, die aktiv angegriffen wird. Schon die GraphQL-Code-Injection CVE-2026-19478 war fast unmittelbar nach ihrer Veröffentlichung aktiv ausgebeutet worden. GitLab ist für Angreifer aus naheliegenden Gründen attraktiv: Ein erfolgreicher Zugriff offenbart Quellcode, CI/CD-Secrets und Anmeldedaten. Zudem lässt sich Schadcode in Build-Pipelines einschleusen, wodurch nachgelagerte Systeme kompromittiert oder manipuliert werden können.
Zusätzliche Gefahr: Unsichere Deserialisierung in GitLab Enterprise Edition
In den Versionen 19.3.2, 19.2.6 und 19.1.8 hat GitLab außerdem eine weitere kritische Schwachstelle behoben. Die unter CVE-2026-87719 bekannt gewordene Lücke trägt einen CVSS-Score von 9.9 und betrifft ausschließlich die Enterprise Edition (EE). Sie wird als unsichere Deserialisierung eingestuft und kann zur Offenlegung sensibler Informationen führen.
Konkret kann ein authentifizierter Benutzer mit Duo-Chat-Zugriff mithilfe eines speziell präparierten GraphQL-Subscription-Arguments die Serialisierung umgehen und auf dem Server gespeicherte Objekte auslesen. Dadurch lassen sich Konfigurationen der Advanced-Search-Instanz sowie sensible Zugangsdaten offenlegen. Da für diese Schwachstelle eine Authentifizierung erforderlich ist, ist die Angriffsfläche etwas kleiner. Dennoch ist sie wegen der hohen Vertraulichkeit der betroffenen Daten als kritisch einzustufen.
Jetzt handeln: Empfehlungen für Administratoren
Betreiber selbst gehosteter GitLab-Instanzen sollten die für ihre Versionsreihe vorgesehenen Updates 19.3.2, 19.2.6 oder 19.1.8 so schnell wie möglich einspielen. Ist ein Update kurzfristig nicht möglich, sollte der öffentliche Zugriff auf die GitLab-Instanz eingeschränkt werden, sofern dieser nicht zwingend erforderlich ist. Die Gefahr einer massenhaften und wahllosen Ausnutzung ist hoch, und das Zeitfenster für Gegenmaßnahmen ist entsprechend klein.
Zusätzlich sollten Administratoren ihre Log-Dateien auf HTTP-POST-Anfragen an den Endpunkt /api/v4/projects/{id}/repository/commits/ überprüfen, insbesondere auf Parameter wie file.Path. Solche Einträge können erste Anzeichen für Ausnutzungsversuche sein.
Die schnelle Aufeinanderfolge kritischer GitLab-Schwachstellen zeigt, dass Entwicklungswerkzeuge längst im Fokus von Angreifern stehen. GitLab-Instanzen sind keine rein internen Systeme mehr, sondern oft direkt mit cloudbasierten CI/CD-Umgebungen, Container-Registries und Deployment-Pipelines verbunden. Ein einziger Dateizugriff kann ausreichen, um eine gesamte Software-Lieferkette zu kompromittieren. Verantwortliche sollten das aktuelle Patchlevel nicht nur als Wartungsaufgabe betrachten, sondern als zentrale Sicherheitsmaßnahme kontinuierlich überwachen.
