GitLabs Path-Traversal mit Bestwertung wird bereits in freier Wildbahn ausgelotet

GitLab hat eine Schwachstelle mit Höchstwertung geschlossen, die es einem nicht authentifizierten Angreifer ermöglicht, beliebige Dateien von einem selbst betriebenen GitLab-Server zu lesen. Und schon etwa einen Tag, nachdem der Fix veröffentlicht wurde, beobachteten Sicherheitsforscher Versuche, ungepatchte Instanzen im offenen Internet aufzuspüren.

Zum Weiterlesen: Fortinets FortiMail-Zero-Day erlaubt Angreifern, Dateien ohne Anmeldung zu schreiben · Google schließt CVE-2026-58704, eine aktiv ausgenutzte Zero-Day-Lücke im Pixel-Modem.

Der Fehler, geführt als CVE-2026-85706, trägt einen CVSS-Wert von 10,0, die Spitze der Skala. Es handelt sich um ein Path-Traversal-Problem in der Repository-Commits-API, und GitLabs eigene Beschreibung ist unverblümt, was die Ursache angeht: „unsachgemäße Pfadisolation und fehlende Durchsetzung der Authentifizierung" in diesem Endpunkt. In der Praxis heißt das: Ein Angreifer, der den Server über das Netzwerk erreichen kann, braucht kein Konto, kein Token und keine Nutzerinteraktion, um ihn nach Dateien zu fragen, die er nie hätte herausgeben dürfen.

GitLab lieferte Fixes in den Versionen 19.1.8, 19.2.6 und 19.3.2 aus und forderte Kunden mit selbst betriebenen Installationen auf, sofort zu aktualisieren. „Diese Versionen enthalten wichtige Fehler- und Sicherheitskorrekturen, und wir empfehlen dringend, alle selbst betriebenen GitLab-Installationen umgehend auf eine dieser Versionen zu aktualisieren", schrieb das Unternehmen in seinen Patch-Release-Hinweisen. GitLab erklärte, der eigene gehostete Dienst GitLab.com laufe bereits mit dem gepatchten Code, und Kunden von GitLab Dedicated müssten nicht tätig werden, womit sich die Exposition auf jene Organisationen konzentriert, die GitLab auf ihrer eigenen Infrastruktur betreiben.

Warum ein Datei-Lesefehler eine 10,0 ist

Es ist verlockend, „beliebige Dateien lesen" als ein geringeres Problem zu betrachten als Remote-Code-Ausführung. Im Kontext einer Plattform, die Quellcode, Pipeline-Definitionen, Deploy-Keys und Zugriffstoken speichert, zerfällt dieser Unterschied. Eine Datei, die von einem GitLab-Server gelesen werden kann, enthält genau das Material, das ein Eindringling braucht, um von einer anonymen Netzwerkanfrage bis zur Kontrolle über die Software-Lieferkette zu gelangen: Administrator-Anmeldedaten, CI/CD-Geheimnisse, Datenbank-Verbindungszeichenfolgen, Signaturschlüssel und die API-Token, mit denen automatisierte Systeme Code pushen oder Pipelines verändern können.

Der CVSS-Vektor legt dar, warum die Schwachstelle an der Obergrenze rangiert. Sie ist übers Netzwerk ausnutzbar (AV:N), von geringer Komplexität (AC:L), benötigt keine Berechtigungen (PR:N) und keine Nutzerinteraktion (UI:N) und hat einen geänderten Geltungsbereich (S:C), die Schwachstelle in einer Komponente erlaubt es einem Angreifer, Ressourcen darüber hinaus zu beeinflussen. Vertraulichkeit und Integrität werden beide hoch bewertet.

Der Abschnitt „Betroffene Versionen" in GitLabs Advisory ist ungewöhnlich weit gefasst. Alles von Version 18.7 bis zu den gepatchten Releases ist betroffen: GitLab Community Edition und Enterprise Edition vor 19.1.8 im 19.1-Zweig, vor 19.2.6 in 19.2 und vor 19.3.2 in 19.3. Das ist ein großer Teil aller selbst betriebenen Installationen, die im vergangenen Jahr einigermaßen aktuell gehalten wurden.

GitLabs Fix kam zusammen mit mehreren anderen Sicherheitspatches im selben Release, darunter ein kritisches Insecure-Deserialization-Problem im GraphQL-Subscription-Serializer, das die Enterprise Edition betrifft, und eine Reihe hochgradiger Fehler, die einen Pufferüberlauf, einen Autorisierungsfehler im CI/CD-Variablenbereich und zwei Denial-of-Service-Schwachstellen in der GraphQL-Komplexitätsbegrenzung umfassen. Das Path-Traversal ist jenes, das den Zeitplan bestimmte, denn es war vor der Authentifizierung ausnutzbar.

Der Forscher, der es meldete, tat dies über GitLabs Bug-Bounty-Programm auf HackerOne unter dem Handle „s3ntago", laut BleepingComputer. Das ist für Verteidiger auf praktische Weise wichtig: Weil die Schwachstelle verantwortungsvoll offengelegt wurde, existierten Patches, bevor die Details öffentlich wurden, der Unterschied zwischen einem Patch-Wettlauf und einer Niederlage.

Das Sondierungsfenster maß sich in Stunden

Es blieb nicht lange ruhig. Das Sicherheitsunternehmen watchTowr, das ein Sensornetzwerk für aufkommende Ausnutzung betreibt, erklärte, es habe fast unmittelbar nach dem Advisory reale Versuche beobachtet, anfällige GitLab-Server zu lokalisieren.

„Angesichts der Geschichte ist der Übergang dieser Schwachstelle zu unterschiedsloser Massenausnutzung wahrscheinlich nicht weit, und Verteidiger haben wenig Zeit zu handeln", sagte watchTowrs Ben Knott in Kommentaren, die The Hacker News veröffentlichte. Das Unternehmen veröffentlichte eine Erkennungssignatur für Verteidiger: Es gelte, nach HTTP-POST-Anfragen an URIs der Form /api/v4/projects/{id}/repository/commits/ zu suchen, die einen Parameter file.Path tragen, die Gestalt, die eine Exploit-Anfrage annimmt.

Bis zum 11. September hatte CISA CVE-2026-85706 in seinen Katalog bekannter ausgenutzter Schwachstellen (Known Exploited Vulnerabilities) aufgenommen, was Bundesbehörden eine verbindliche Frist setzt, zu patchen oder kompensierende Kontrollen zu dokumentieren. Die KEV-Aufnahme ist das stärkste öffentliche Signal, das ohne eine Bestätigung des Herstellers auskommt, dass ein Fehler genutzt und nicht bloß untersucht wird.

Die Lücke zwischen Offenlegung und Sondierung misst sich heute in Stunden statt in Wochen, und diese Verdichtung ist selbst die Geschichte der schwerwiegendsten Infrastrukturfehler des Jahres 2026. Angreifer automatisieren zunehmend die Suche nach frisch offengelegten Schwachstellen, sodass die nützliche Frage nicht lautet, ob ein Fehler ins Visier gerät, sondern wie schnell eine gegebene Organisation ihre exponierten Systeme erfassen, patchen und überprüfen kann. Für GitLab-Betreiber ist das Inventarproblem größer, als es aussieht: Eine einzige Organisation kann viele selbst betriebene Instanzen unterhalten (regionale Bereitstellungen, Staging-Cluster, projektspezifische Server), und ein Schwachstellen-Scanner, der nur die primäre Produktionsinstanz abdeckt, wird die Kopien übersehen, auf die es ankommt.

Reaktion auf CVE-2026-85706

Der Behebungspfad ist in groben Zügen geradlinig und in der Ausführung anspruchsvoll. Aktualisieren Sie selbst betriebene Instanzen auf 19.1.8, 19.2.6 oder 19.3.2 im passenden Zweig oder auf ein späteres Release. Wo ein sofortiges Upgrade unmöglich ist, beschränken Sie den Netzwerkzugriff auf die Repository-Commits-API und allgemein auf die GitLab-Instanz, denn die Schwachstelle erfordert, dass der Angreifer den Server direkt erreicht.

Weil die Schwachstelle ein Datei-Leseproblem ist, ist „patchen und vergessen" keine vollständige Antwort. GitLab-Server enthalten üblicherweise Anmeldedaten, die ein Software-Update überdauern: persönliche Zugriffstoken, CI/CD-Job-Token, Deploy-Keys, known_hosts-Material und die Inhalte von Konfigurationsdateien. Sicherheitsteams, die während des Expositionsfensters eine aus dem Internet erreichbare Instanz im betroffenen Bereich hatten, sollten Anmeldedaten rotieren, die vom Dateisystem aus erreichbar waren, und GitLab-Zugriffsprotokolle auf ungewöhnliche Zugriffe auf die Commits-API prüfen. WatchTowrs Erkennungshinweis ist eine sinnvolle Ausgangsabfrage, doch das Fehlen passender Protokollzeilen ist kein Beweis für Sicherheit, Protokolle rotieren, und ein sorgfältiger Angreifer liest nichts, was auffallen würde.

Unter dem technischen Punkt liegt ein Governance-Punkt. Der Grund, warum eine 10,0 in einer Quellcode-Plattform mehr zählt als eine 10,0 in einer peripheren Anwendung, ist, dass selbst betriebenes GitLab oft die vertrauenswürdige Wurzel der Build-Pipeline einer Organisation ist. Was ein Angreifer dort lesen kann, reicht konstruktionsbedingt aus, um die Software zu verändern, der alle nachgelagert vertrauen. Dieses System als Bequemlichkeitsinstallation statt als kritische Sicherheitsgrenze zu behandeln, ist der Fehler, den diese Schwachstelle offenlegt.

Das breitere Muster

CVE-2026-85706 fällt in eine dicht gedrängte Saison kritischer Fehler in Entwickler- und IT-Infrastruktur. Binnen weniger Wochen wurden Organisationen aufgefordert, einen Token-Verkettungsfehler in JFrog Artifactory zu patchen, der eine anonyme Anfrage in ein Administrator-Token verwandeln könnte, ein Paar Vor-Authentifizierungs-Fehler in SAPs Kernel und NetWeaver Message Server, einen Fehler im Vorverkaufspfad der Druckmanagement-Server von PaperCut und einen kritischen Zero-Day in der Remote-Management-Plattform N-central von N-able. Der gemeinsame Nenner: Die anfällige Software sitzt innerhalb des Perimeters, hält oft die Schlüssel zu allem dahinter und wird häufig nicht im selben Rhythmus gepatcht wie die aus dem Internet erreichbaren Anwendungen, die mehr Aufmerksamkeit erhalten.

Der Grund, warum diese Fehler sich häufen, ist strukturell. Entwickler- und IT-Plattformen sind darauf ausgelegt, von allem um sie herum vertraut zu werden: Sie halten Anmeldedaten, sie sitzen im Netzwerk, und sie werden meist von einem kleinen Team verwaltet, das ohnehin überlastet ist. Diese Kombination macht sie zu attraktiven Zielen und langsam zu patchen, weil ein Upgrade eine Build-Pipeline oder eine Authentifizierungsintegration brechen kann, die niemand anfassen möchte. CVE-2026-85706 nimmt sogar die Ausrede, Anmeldedaten zu benötigen, die einzige Voraussetzung ist Netzwerkerreichbarkeit, genau jene Eigenschaft, die einen GitLab-Server für ein verteiltes Engineering-Team nützlich macht.

Es gibt zudem ein Messproblem. Organisationen wissen tendenziell, wie viele GitLab-Instanzen sie bewusst betreiben, und haben ein viel unscharferes Bild von jenen, die existieren, weil ein Team eine für ein Projekt hochzog oder die vor Jahren aufgesetzt und nie stillgelegt wurde. Internetweite Scan-Dienste machen es einem Angreifer trivial, diese vergessenen Server zu finden; dieselbe Sichtbarkeit, die es einem Sicherheitsteam erlaubt, seine Exposition zu auditieren, speist auch die Scanner, die darauf zielen. Die praktische Lehre der vergangenen Wochen ist, dass Patch-Management für interne Entwicklerinfrastruktur so aggressiv sein muss wie für die öffentlich sichtbare Edge, und dass das Asset-Inventar (zu wissen, was man tatsächlich betreibt) der schwierige Teil ist.

Für Verteidiger ist die sinnvolle Reihenfolge der Operationen: patchen, dann überprüfen, dass der Patch auf jeder Instanz griff, dann das Fenster untersuchen, in dem ein ungepatchter Server erreichbar war. Anmeldedaten, die das Dateisystem einer exponierten Instanz berührt haben, sollten bis zur Rotation als verdächtig gelten, und Protokolle sollten auf das von watchTowr veröffentlichte file.Path-Muster geprüft werden. Nichts davon garantiert einen sauberen Gesundheitsbericht, aber es ist der Unterschied zwischen der Reaktion auf einen bekannten Fehler und der Entdeckung Monate später, dass er der erste Schritt einer längeren Intrusion war.

Für GitLab konkret ist die praktische Frist jetzt. Der Fix ist verfügbar, die Ausnutzung hat begonnen, und die Kosten der Verzögerung messen sich in Anmeldedaten, die sich nicht so schnell rotieren lassen, wie ein Server aktualisiert werden kann. Organisationen sollten ihre Version bestätigen, ihre Exposition prüfen und annehmen, dass jede während des Fensters offen gelassene Instanz eine Untersuchung wert ist, nicht weil eine Kompromittierung sicher ist, sondern weil die Beweise dafür leise wären und die Folgen, sie zu übersehen, es nicht wären.

Titelbild: TechPastWeek-Original-Komposit unter Verwendung des GitLab-Logos (GitLab Inc., MIT-Lizenz).