GitLab CVE-2026-85706: Unauthentifiziertes Dateilesen (CVSS 10), aktiv ausgenutzt

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Infrastruktursicherheit für Enterprise-Teams in den USA und der EU

Die kurze Antwort

Was ist CVE-2026-85706?

GitLab ist der Ort, an dem die meisten Entwicklungsteams ihre Kronjuwelen aufbewahren: Quellcode, Merge Requests, CI/CD-Pipelines und die Geheimnisse, die diese Pipelines für den Weg in die Produktion brauchen. Am 10. September 2026 veröffentlichte GitLab ein Security-Release, das CVE-2026-85706 behebt — eine kritische Path-Traversal-Schwachstelle in der Repository-Commits-API mit dem Höchstwert CVSS 10.0. Betroffen sind sowohl die kostenlose Community Edition als auch die kostenpflichtige Enterprise Edition über eine breite Spanne aktueller Versionen.

Der Fehler steckt in der API, die Commit-Daten des Repositorys ausliefert. Wegen unzureichender Pfadeinschränkung und fehlender Authentifizierung kann ein Angreifer einen einzigen HTTP-POST an /api/v4/projects/{id}/repository/commits/ mit einem Pfadparameter senden, der aus dem Repository heraustritt und auf jede vom GitLab-Prozess lesbare Datei zeigt. Kein Login, kein Token, keine Nutzerinteraktion — die Anfrage wird beantwortet, bevor die Authentifizierung greift. Einzige Voraussetzung ist mindestens ein öffentliches Projekt auf der Instanz, was auf die allermeisten realen Installationen zutrifft. Da es sich um serverseitige Infrastruktur handelt, ist ihre Härtung ebenso sehr eine DevOps- und Plattform-Aufgabe wie eine Anwendungsfrage.

GitLab.com, das vom Hersteller betriebene SaaS, ist bereits gepatcht — die Gefahr konzentriert sich also auf die geschätzten über 20.000 weltweit betriebenen self-managed GitLab-Instanzen, also die On-Premise- und selbst gehosteten Server, die Unternehmen in Eigenregie betreiben. GitLab hat das Problem in den Releases 19.3.2, 19.2.6 und 19.1.8 behoben, die korrekte Pfadeinschränkung und Authentifizierung am Commits-Endpunkt erzwingen.

Wie eine Anfrage jede Datei liest

Path Traversal ist eine der ältesten Klassen von Web-Schwachstellen, und CVE-2026-85706 ist ein Musterbeispiel mit modernem Schadensradius. Eine API soll den Dateizugriff auf ein bestimmtes Verzeichnis beschränken — hier auf die Daten eines bestimmten Repositorys. Wenn der Code, der einen vom Aufrufer übergebenen Pfad auflöst, ihn nicht normalisiert und einschränkt, erlauben Sequenzen, die im Verzeichnisbaum nach oben klettern, das Verlassen des vorgesehenen Ordners und den Verweis auf Dateien anderswo auf der Platte. Die Commits-API nahm einen Pfadparameter entgegen und verwendete ihn, ohne ausreichend zu begrenzen, wohin er zeigen darf.

Was einen gängigen Bug in einen CVSS-10.0-Notfall verwandelt, ist die Kombination der Faktoren. Der Endpunkt antwortet, bevor die Authentifizierung erzwungen wird, also braucht es keine Zugangsdaten. Er benötigt eine einzige POST-Anfrage, lässt sich also trivial im Internetmaßstab automatisieren. Und er läuft mit den Rechten des GitLab-Prozesses, der die Log- und Konfigurationsdateien des Servers lesen kann. Genau dort liegt das Wertvolle: Datenbank-Verbindungszeichenfolgen, Objektspeicher-Schlüssel, das zum Signieren von Tokens genutzte Instanzgeheimnis und Fragmente von Zugangsdaten, die in Logs gelangen. Wer diese liest, braucht den Dateilese-Bug nicht mehr — er hat gültige Schlüssel.

Das ist nicht theoretisch. Ein watchTowr-Honeypot-Netz beobachtete Angriffsversuche in freier Wildbahn ab ca. 06:00 UTC am 11. September 2026, rund sechs Stunden nach der Offenlegung. Am selben Tag nahm die CISA CVE-2026-85706 in ihren Known-Exploited-Vulnerabilities-Katalog nach der Binding Operational Directive 26-04 auf und setzte US-Bundesbehörden eine Frist bis 14. September 2026. Wenn eine Schwachstelle höchsten Schweregrads innerhalb eines Vormittags vom Advisory zum aktiven Scannen wird, ist das Zeitfenster für ruhiges Patchen bereits geschlossen.

Was das für Softwareteams in der DACH-Region bedeutet

Streicht man die CVE-Nummer, bleiben drei dauerhafte Lehren. Erstens: Ihr Quellcode-Server ist Produktionsinfrastruktur, kein Entwickler-Komfort. Teams häufen Authentifizierung, WAFs und Rate-Limiting auf kundennahe Apps und betreiben dann ein selbst gehostetes GitLab in einem freizügigen Netz, weil „es ja nur unsere Repos“ sind. Doch diese Maschine hält die Zugangsdaten zu Ihrer Cloud und den Code, der zur Produktion wird. Sie verdient dasselbe Bedrohungsmodell wie Ihr Edge — und dieselbe Patch-Dringlichkeit.

Zweitens: Ein Dateilesen ist ein Geheimnislesen, und ein Geheimnislesen ist ein Supply-Chain-Ereignis. Der Grund, warum diese Lücke so hoch bewertet wird wie eine Remote-Code-Execution, ist, dass die offengelegten Dateien die Schlüssel zu allem Nachgelagerten enthalten. Sind erst CI/CD-Variablen, Deploy-Tokens oder Signaturmaterial abgeflossen, kann ein Angreifer in Ihre Cloud-Konten eindringen oder die an Kunden ausgelieferten Artefakte manipulieren. Deshalb reicht Patchen allein hier nicht: War die Instanz erreichbar, müssen Sie davon ausgehen, dass Geheimnisse das Haus verlassen haben, und sie rotieren.

Drittens: Netzexposition ist der Multiplikator, und Zeit ist der Feind. Der Unterschied zwischen „kritischem CVE, das wir in Ruhe gepatcht haben“ und „Vorfall“ ist fast immer, ob der verwundbare Dienst von dort erreichbar war, wo der Angreifer sitzt — und wie schnell Sie reagiert haben. Genau zu wissen, welche internen Dienste aus dem Internet erreichbar sind, und sie innerhalb von Stunden patchen zu können, ist die wirkungsvollste Kontrolle, in die Sie investieren können.

Was jetzt zu tun ist

1. Sofort auf eine gepatchte Version aktualisieren. Bringen Sie jedes self-managed GitLab auf einer betroffenen Version — 18.7–19.1.7, 19.2.0–19.2.5 oder 19.3.0–19.3.1 — auf 19.3.2, 19.2.6 oder 19.1.8. Behandeln Sie das als Notfalländerung, nicht als Routinewartung.
2. Geheimnisse in der Annahme einer Kompromittierung rotieren. War die Instanz aus dem Internet erreichbar, rotieren Sie CI/CD-Variablen, Deploy- und Access-Tokens, Datenbank- und Objektspeicher-Zugangsdaten, das GitLab-Instanzgeheimnis und alle in Pipelines gespeicherten Cloud-Schlüssel. Patchen stoppt künftige Zugriffe; es macht das bereits Entwendete nicht ungeschehen.
3. GitLab aus nicht vertrauenswürdigen Netzen nehmen. Ein Quellcode-Server sollte nur aus vertrauenswürdigen Subnetzen oder hinter VPN bzw. Zero-Trust-Proxy erreichbar sein. Ist öffentlicher Internetzugang keine harte Anforderung, entfernen Sie ihn — das allein neutralisiert diese Angriffsklasse.
4. Nach Ausnutzung suchen. Prüfen Sie Zugriffslogs auf POST-Anfragen an /api/v4/projects/{id}/repository/commits/ mit ungewöhnlichen oder Traversal-artigen Pfadparametern und achten Sie auf unerwartete Repository-Klone oder neu erstellte Tokens. Sichern Sie Logs, bevor sie rotieren.
5. Ihre DevOps-Ebene ins Security-Testing aufnehmen. Selbst gehostetes GitLab, Registries und CI-Runner bleiben oft außen vor, obwohl sie die sensibelsten Assets halten. Nehmen Sie sie in Ihren nächsten Penetrationstest auf und prüfen Sie benachbarte interne Dienste auf ähnliche Pre-Auth-Pfade.

Häufige Fragen

Quellen

The Hacker News — GitLab CVSS 10 File-Read Flaw Draws In-the-Wild Probes After Disclosure
Forkast — GitLab’s CVSS 10 Commits-API Flaw Hits Active Exploitation Within Hours
CISA — Known Exploited Vulnerabilities Catalog