CVE-2026-85706: Kritische GitLab Pfadüberquerungsschwachstelle wird in freier Wildbahn ausgenutzt

GitLab hat dringende Sicherheitsupdates für eine Sicherheitslücke mit höchster Schwere in der Community Edition (CE) und Enterprise Edition (EE) veröffentlicht, die es nicht authentifizierten Angreifern ermöglicht, beliebige Dateien von anfälligen Servern zu lesen. Verfolgt als CVE-2026-85706 und mit 10,0 auf der CVSS-Skala bewertet, liegt der Fehler in der Repository-Commits-API und resultiert aus unzureichender Pfadbeschränkung in Verbindung mit unzureichender Authentifizierung.

Das Risiko stieg fast sofort nach der Offenlegung. Sicherheitsforscher beobachteten ab etwa 06:00 UTC am 11. September 2026, kurz nachdem GitLab Patches veröffentlicht hatte, internetweites Sondieren. CISA fügte die Sicherheitsanfälligkeit aufgrund von Beweisen für aktive Ausnutzung zu seinem Katalog für bekannte ausgenutzte Sicherheitsanfälligkeiten hinzu.

Eine erfolgreiche Ausnutzung kann sensible Dateien offenlegen, die auf dem GitLab-Server gespeichert sind, einschließlich Konfigurationsdaten, Anmeldeinformationen, Geheimnisse, Protokolle und andere Informationen, die für den GitLab-Dienst zugänglich sind. In Entwicklungsumgebungen können diese Dateien CI/CD-Geheimnisse, Bereitstellungsanmeldeinformationen, Token, quellcodebezogene Daten und Informationen enthalten, die eine Folgekompromittierung unterstützen könnten.

Der Fehler ist besonders gefährlich für internetfähige selbstverwaltete GitLab-Installationen, da die Ausnutzung kein Konto, keine bestehenden Berechtigungen oder Nutzerinteraktion erfordert. Laut watchTowr ist die wichtigste Voraussetzung für den beobachteten Angriffsweg, dass die GitLab-Instanz mindestens ein öffentliches Projekt enthält.

Analyse von CVE-2026-85706

Die Sicherheitsanfälligkeit ist ein Pfadauslassungsproblem in GitLabs Repository-Commits-API. GitLab beschreibt die Hauptursache als unzureichende Eindämmung der Dateipfade in Verbindung mit der fehlenden Authentifizierung der betroffenen Funktionalität. Dies ermöglicht es einem Angreifer, pfadgesteuerte Informationen zu kontrollieren, den Standort zu verlassen, an dem GitLab erwartet, dass sich Repository-Dateien befinden, und auf andere Dateien zu verweisen, die für die Anwendung verfügbar sind.

Der von GitLab zugewiesene CVSS-Vektor ist CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. Er spiegelt eine aus der Ferne ausnutzbare Sicherheitsanfälligkeit mit niedriger Angriffskomplexität, ohne Authentifizierungsanforderung und ohne Nutzerinteraktion wider. GitLab weist hohe Vertraulichkeits- und Integritätsauswirkungen zu, während die Verfügbarkeit nicht direkt von der Dateilesefunktion selbst betroffen ist.

Die wichtigsten Details zu CVE-2026-85706 sind, dass Angreifer aus der Ferne mit der anfälligen Repository-Commits-API interagieren und Pfade anfordern können, die außerhalb des erlaubten Repository-Verzeichnisses liegen sollten. Wenn GitLab diesen Pfad nicht korrekt einschränkt, kann der Server den Inhalt einer beliebigen Datei zurückgeben, die für den GitLab-Prozess zugänglich ist.

Laut watchTowr kann die Ausnutzung GitLab-spezifische Konfigurations- und Protokolldateien offenlegen, die Anmeldeinformationen, Geheimnisse und andere sensible Informationen enthalten. Abhängig von der Systemkonfiguration und den Dateiberechtigungen können Angreifer auch SSH-Schlüssel, Umgebungsdateien, Datenbankanmeldeinformationen, Bereitstellungs-Token oder andere sensible Anwendungsdaten anvisieren.

CVE-2026-85706 betrifft die folgenden GitLab CE- und EE-Versionen:

• Alle Versionen ab 18.7 vor 19.1.8
• Alle Versionen ab 19.2 vor 19.2.6
• Alle Versionen ab 19.3 vor 19.3.2

GitLab.com lief bereits auf der gepatchten Version, als das Problem öffentlich bekannt wurde, während GitLab Dedicated-Kunden keine Maßnahmen ergreifen müssen. Die dringende Anforderung zur Behebung betrifft in erster Linie Organisationen, die selbstverwaltete GitLab-Instanzen betreiben.

Die Anforderung von mindestens einem öffentlichen Projekt erhöht die Gefährdung von Organisationen erheblich, die absichtlich Open-Source-Repositorys, öffentliche Entwicklungsprojekte, Gemeinschaftsressourcen oder andere anonym zugängliche Inhalte auf ihrer eigenen GitLab-Infrastruktur hosten. Ein Angreifer benötigt keine Mitgliedschaft im Projekt oder ein gültiges GitLab-Konto, bevor er einen Ausnutzungsversuch unternimmt.

Die Konsequenzen können über die bloße Offenlegung von Informationen hinausgehen. GitLab steht häufig im Zentrum von Softwareentwicklungspipelines und speichert hochsensible Materialien, einschließlich Quellcode, CI/CD-Variablen, Bereitstellungsanmeldeinformationen, Infrastrukturkonfigurationen, Zugriffstoken und Integrationsgeheimnisse.

Wenn ein Angreifer solche Anmeldeinformationen durch beliebigen Dateizugriff erlangt, kann die anfängliche GitLab-Sicherheitsanfälligkeit zu einem Ausgangspunkt für weitere Eindringversuche werden. Gestohlene Geheimnisse könnten potenziell Zugriff auf Quellcode-Repositorys, CI/CD-Infrastruktur, Cloud-Dienste, Containerregistries, Bereitstellungssysteme oder andere verbundene Ressourcen ermöglichen.

Dies führt auch zu einem Risiko in der Software-Supply-Chain. Der Zugriff auf Entwicklungsanmeldeinformationen oder Build-Infrastruktur könnte es einem Angreifer ermöglichen, unbefugte Änderungen an Repositorys vorzunehmen, Build-Prozesse zu manipulieren, proprietären Code zu stehlen oder nachgelagerte Systeme zu kompromittieren, die auf durch die betroffene GitLab-Umgebung erzeugte Artefakte vertrauen.

GitLab würdigte den Sicherheitsforscher s3ntago für die Meldung der Sicherheitsanfälligkeit über das HackerOne-Bug-Bounty-Programm des Unternehmens. Das genaue private Entdeckungs- und Meldedatum wurde nicht öffentlich bekannt gegeben. GitLab veröffentlichte die gepatchten Versionen am 10. September 2026 und dokumentierte den Fehler als Teil seiner kritischen Patch-Veröffentlichung öffentlich.

Der Übergang von der Offenlegung zu feindlichen Aktivitäten erfolgte äußerst schnell. WatchTowr erklärte, dass sein Angreifer-Augen-Honeypot-Netzwerk Verhaltenssonden bemerkte, die die Sicherheitslücke ab etwa anvisierten 06:00 UTC am 11. September, was darauf hindeutet, dass externe Akteure die Schwachstelle bereits rückentwickelt und begonnen hatten, internetzugängliche GitLab-Systeme zu testen.

CISA fügte den Fehler später am 11. September seinem KEV-Katalog hinzu, nachdem Beweise für aktive Ausnutzung bestätigt worden waren. Bundesagenturen der zivilen Exekutive wurden angewiesen, betroffene Systeme bis 14. September 2026zu beheben, und CISA kennzeichnete die Sicherheitsanfälligkeit auch als erforderlich für eine forensische Untersuchung gemäß der verbindlichen Betriebsanweisung 26-04.

Öffentlicher CVE-2026-85706 PoC-Code erschien ebenfalls kurz nach der Offenlegung, was die technische Barriere für Angreifer, die daran interessiert sind, das beliebige Dateileseverhalten zu reproduzieren, weiter senkte. In Kombination mit der geringen Schwierigkeitsgrad und dem nicht authentifizierten Angriffspfad der Sicherheitsanfälligkeit erhöht die öffentliche Reproduktion die Wahrscheinlichkeit breiter opportunistischer Ausnutzung.

Derzeit gibt es keinen umfassenden Satz von kampagnenspezifischen CVE-2026-85706 IOCs wie Angreifer-IP-Adressen, Domains oder Malware-Hashes, die eine Ausnutzung zuverlässig identifizieren können. Stattdessen ist das nützlichste Indikator die Struktur von Anfragen, die auf die anfällige GitLab-API abzielen.

WatchTowr empfiehlt, nach HTTP POST-Anfragen zu suchen, die auf Pfade mit folgendem Muster gerichtet sind:

/api/v4/projects/{id}/repository/commits/

Verteidiger sollten besonders aufpassen, wenn diese Anfragen verdächtige file.Path-Parameter enthalten oder versuchen, Dateien abzurufen, die nicht mit dem zugänglichen Repository in Verbindung stehen.

CVE-2026-85706 Minderung

GitLab empfiehlt dringend, dass alle betroffenen selbstverwalteten Installationen sofort auf eine der gepatchten Versionen aktualisieren:

• GitLab 19.1.8
• GitLab 19.2.6
• GitLab 19.3.2

Jede spätere unterstützte Version, die den Sicherheitsfix enthält, sollte ebenfalls die Sicherheitsanfälligkeit adressieren. Administratoren sollten die genaue laufende Version überprüfen, anstatt anzunehmen, dass ein automatisches Update stattgefunden hat.

Organisationen, die nicht sofort patchen können, sollten unnötigen öffentlichen Zugriff auf die betroffene GitLab-Instanz entfernen oder die Konnektivität auf Ebene des Reverse-Proxy, der Firewall, des Lastenausgleichs oder des Netzwerks einschränken, bis das Upgrade abgeschlossen werden kann. Dies ist nur eine temporäre Maßnahme zur Reduzierung der Exposition und sollte die Installation der von GitLab gepatchten Version nicht ersetzen.

Die Erkennung von CVE-2026-85706 sollte damit beginnen, alle selbstverwalteten GitLab-Instanzen, ihre genauen Versionen und die Frage zu identifizieren, ob sie nach dem 10. September über das Internet zugänglich waren. Systeme, die ein oder mehrere öffentliche Projekte hosten, sollten eine besonders hohe Priorität bei der Untersuchung haben.

Um die Ausnutzung oder Aufklärung von CVE-2026-85706 zu erkennen, sollten Verteidiger GitLab-, Reverse-Proxy-, WAF- und Webserver-Telemetrie auf Folgendes überprüfen:

• HTTP POST-Anfragen an /api/v4/projects/{id}/repository/commits/
• Anfragen mit ungewöhnlichen file.Path-Parametern
• Pfadauslassungssequenzen, die versuchen, die erwarteten Repository-Verzeichnisse zu verlassen
• Anfragen nach GitLab-Konfigurations- oder Protokolldateien über Repository-APIs
• Große Anzahl von Repository-Commits-API-Anfragen von bisher unbekannten Quellen
• Anonymer Zugriff gefolgt von ungewöhnlichen Versuchen, serverseitige Ressourcen abzurufen
• Unerwarteter Zugriff auf Anmeldeinformationen, Konfigurationsdateien oder Anwendungsgeheimnisse
• Neue Authentifizierungsaktivitäten mit Anmeldeinformationen, die möglicherweise durch GitLab offengelegt wurden
• Unerklärter Zugriff auf CI/CD-, Cloud-, Registry- oder Bereitstellungsinfrastruktur nach verdächtiger GitLab-Aktivität

WatchTowr empfiehlt, das Repository-Commits-API-Muster zu überprüfen, da es direkten Beweis für Sondierungs- oder Ausnutzungsversuche gegen den anfälligen Endpunkt liefern kann.

Patching sollte auch mit einer retrospektiven Untersuchung kombiniert werden. Die Anforderung von CISA für eine forensische Untersuchung spiegelt die Möglichkeit wider, dass Organisationen vor der Implementierung der Lösung kompromittiert worden sein könnten, insbesondere angesichts der schnellen Angriffe nach der Offenlegung.

Wenn verdächtige Leseaktivität bei Dateien erkannt wird, sollten Administratoren genau bestimmen, welche Dateien möglicherweise zugegriffen wurden. Geheimnisse, die in potenziell offenbarten Dateien enthalten sind, sollten als kompromittiert betrachtet werden, bis das Gegenteil bewiesen ist.

Organisationen sollten in Betracht ziehen, folgende Daten zu rotieren:

• GitLab-Zugangs- und persönliche Zugriffstoken
• Bereitstellungstoken
• CI/CD-Variablen und -Geheimnisse
• Datenbankanmeldeinformationen
• SSH-Schlüssel
• Cloud-Anmeldeinformationen
• Container-Registry-Anmeldeinformationen
• API- und Integrationstoken
• OAuth-Geheimnisse
• Bereitstellungs- und Automatisierungsanmeldeinformationen

Sicherheitsteams sollten auch nachgelagerte Systeme untersuchen, die diesen Anmeldeinformationen vertraut haben. Ein Update von GitLab schließt den anfälligen Dateilesepfad, aber kann nicht garantieren, dass Geheimnisse bereits von einem Angreifer erlangt wurden.

Für Hochrisikosysteme sollten Verteidiger jüngste Aktivitäten in Repositorys, Pipelines, Accounts, Runnern und Bereitstellungen mit bekannten Guten zeichnen, um potenziellen Folge-Missbrauch zu identifizieren. Unerwartete Pipeline-Modifikationen, Repository-Änderungen, neu ausgegebene Token oder ungewöhnlicher Zugriff auf die Build-Infrastruktur sollten untersucht werden.

Angesichts der CVSS-Schwere von 10,0, bestätigter Ausnutzung, öffentlicher Reproduktion und der schnellen Übergangs von der Offenlegung zum Scannen sollte die Behebung als Notfall für internetfähige selbstverwaltete GitLab-Installationen behandelt werden.