GitLab CVE-2026-85706: Pfad-Traversal in der Commits-API erlaubt unauthentifiziertes Auslesen beliebiger Dateien — aktiv ausgenutzt, CVSS 10.0, jetzt in der CISA-KEV
GitLab hat am 10. September 2026 CVE-2026-85706 veröffentlicht: eine Pfad-Traversal-Schwachstelle (CWE-22) in der Commits-API von Self-Managed-Installationen. Der Fehler kombiniert unzureichende Pfad-Eingrenzung mit fehlender Authentifizierungs-Prüfung am Endpunkt /api/v4/projects/{id}/repository/commits/ — ein einzelner unauthentifizierter Request liest beliebige Dateien vom Server. CVSS 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N). watchTowr und Rapid7 bestätigen aktive Ausnutzung seit dem 11. September 2026, CISA hat die Lücke am 15. September 2026 in die Known Exploited Vulnerabilities-Liste aufgenommen. Betroffen sind GitLab CE und EE von 18.7 bis 19.3.1, gepatcht in 19.1.8, 19.2.6 und 19.3.2. GitLab.com und GitLab Dedicated sind nicht betroffen.
TL;DR — 90 Sekunden
Eine Pfad-Traversal-Lücke in der GitLab-Commits-API erlaubt unauthentifizierten Angreifern das Auslesen beliebiger Dateien vom Server. CVSS 10.0, der Maximalwert der Skala. Aktive Ausnutzung ist seit dem 11. September 2026 bestätigt, CISA hat die Lücke vier Tage später in die KEV-Liste aufgenommen. Betroffen sind ausschließlich Self-Managed-Instanzen (Omnibus, Quellcode, Helm-Chart) der Versionen 18.7 bis 19.3.1. Der Patch liegt in 19.1.8, 19.2.6 und 19.3.2 vor. Wer nicht sofort patchen kann, sollte die Instanz aus dem öffentlichen Netz nehmen.
Was ist das Problem?
Der verwundbare Endpunkt liegt in der Commits-API unter /api/v4/projects/{id}/repository/commits/. Ein Parameter zur Datei-Pfad-Angabe wird nicht ausreichend gegen Directory-Traversal-Sequenzen geprüft. Kombiniert mit einer fehlenden Authentifizierungs-Prüfung an dieser Stelle kann ein Angreifer ohne Zugangsdaten beliebige Dateien vom Dateisystem des GitLab-Servers auslesen — etwa Konfigurationsdateien, Secrets oder private SSH-Schlüssel.
Die Schwachstelle betrifft ausschließlich Self-Managed-Installationen. GitLab.com und GitLab Dedicated werden von GitLab selbst betrieben und sind separat gehärtet — dort ist keine Handlung nötig.
Wer ist betroffen?
Alle Self-Managed-Deployments von GitLab CE und EE in den folgenden Versionsbereichen:
| Versionsbereich | Status | Fix-Version |
|---|---|---|
| 18.7 – 19.1.7 | Betroffen | 19.1.8 |
| 19.2.0 – 19.2.5 | Betroffen | 19.2.6 |
| 19.3.0 – 19.3.1 | Betroffen | 19.3.2 |
| GitLab.com / GitLab Dedicated | Nicht betroffen | — |
Maßgeblich ist die Installationsart, nicht die Unternehmensgröße: Jede selbst gehostete Instanz in den genannten Versionsbereichen ist betroffen, unabhängig davon, ob sie öffentlich oder nur intern erreichbar ist.
Auswirkungen
Ein erfolgreicher Angriff liest Dateien mit den Rechten des GitLab-Prozesses — typischerweise reicht das für gitlab-secrets.json, Datenbank-Konfigurationsdateien oder private SSH-Schlüssel im Home-Verzeichnis des GitLab-Nutzers. Aus einem reinen Datei-Lesezugriff wird so häufig ein Sprungbrett zu vollständiger Instanz-Kompromittierung: Secrets erlauben das Fälschen von Sessions, SSH-Schlüssel erlauben Repository-Zugriff und CI/CD-Pipeline-Manipulation.
Da CI/CD-Pipelines häufig produktive Deploy-Credentials enthalten, reicht die Kette in vielen Setups bis in die Produktionsumgebung — aus einem unauthentifizierten Lesezugriff wird potenziell eine vollständige Kompromittierung der Lieferkette.
Mitigation / Sofortmaßnahmen
Patchen Sie umgehend, außerhalb des regulären Wartungsfensters. Aktualisieren Sie Ihre Self-Managed-Instanz über den für Ihre Installationsart vorgesehenen Weg (Omnibus-Paketmanager, Source-Update-Skript oder Helm-Chart-Upgrade) auf 19.1.8, 19.2.6 oder 19.3.2 — je nach aktueller Minor-Version. Das Update enthält Datenbank-Migrationen; auf Single-Node-Systemen ist mit kurzer Downtime während der Migration zu rechnen, planen Sie diese ein.
Ist ein sofortiges Patchen nicht möglich, nehmen Sie die Instanz aus dem öffentlichen Netz oder schränken Sie den Zugriff auf die Commits-API über eine vorgelagerte Firewall bzw. einen Reverse-Proxy auf bekannte IP-Bereiche ein. Das ist ausdrücklich nur eine Übergangslösung — ein öffentlich dokumentiertes WAF-Pattern für diese Lücke liegt derzeit nicht vor.
Detection / Prüfung
Werten Sie die GitLab-Access-Logs (production_json.log bzw. den vorgelagerten Reverse-Proxy) auf POST-Requests gegen /api/v4/projects/{id}/repository/commits/ mit einem Datei-Pfad-Parameter aus, der Traversal-Sequenzen (../) oder absolute Pfade außerhalb des Repository-Verzeichnisses enthält.
Prüfen Sie zusätzlich, ob seit dem 10. September 2026 unerwartete Zugriffe auf sensible Pfade wie /etc/gitlab/gitlab-secrets.json oder .ssh/-Verzeichnisse in den Logs auftauchen. CISA und mehrere Sicherheitsanbieter melden aktive Scans im Internet; ein Fund in den Logs ist als Kompromittierungsindiz zu behandeln, nicht nur als Fehlversuch.
Betreiberempfehlung
Akut handeln, wenn: Ihre GitLab-Self-Managed-Instanz aus dem Internet erreichbar ist und eine Version zwischen 18.7 und 19.3.1 läuft — patchen Sie noch heute oder nehmen Sie die Instanz vom Netz.
Beobachten genügt, wenn: Ihre Instanz bereits auf 19.1.8, 19.2.6, 19.3.2 oder neuer läuft, oder Sie ausschließlich GitLab.com bzw. GitLab Dedicated nutzen.
Prüfen Sie in jedem Fall die Zugriffslogs der letzten Woche auf verdächtige Commits-API-Aufrufe, unabhängig vom aktuellen Patch-Stand.
Häufige Fragen zu CVE-2026-85706
Ist GitLab.com von CVE-2026-85706 betroffen?+
Nein. Nur Self-Managed-Installationen (Omnibus, Quellcode, Helm-Chart) sind betroffen. GitLab.com und GitLab Dedicated werden von GitLab selbst betrieben und sind nicht verwundbar.
Genügt eine Firewall-Regel, oder muss ich patchen?+
Der Zugriffsentzug aus dem öffentlichen Netz ist nur eine Übergangslösung. Die einzige verlässliche Behebung ist das Update auf 19.1.8, 19.2.6 oder 19.3.2.
Welche Rechte hat der Angreifer nach einem erfolgreichen Lesezugriff?+
Der Angreifer liest Dateien mit den Rechten des GitLab-Server-Prozesses — kein direkter Shell-Zugriff, aber häufig genug, um über Secrets oder SSH-Schlüssel weiterzukommen.
Verursacht das Update Ausfallzeit?+
Ja, potenziell. Das Update enthält Datenbank-Migrationen; auf Single-Node-Systemen ist mit kurzer Downtime während der Migration zu rechnen. Planen Sie ein Wartungsfenster ein, auch wenn Sie außerplanmäßig patchen.
Gibt es einen öffentlichen Exploit-Code?+
Ein detaillierter Exploit ist öffentlich nicht bestätigt. watchTowr und Rapid7 bestätigen aber, die Lücke selbst reproduziert zu haben, und mehrere Anbieter melden aktive Scans im Internet.
Fazit
CVE-2026-85706 zeigt erneut, wie schnell aus einem einzelnen unauthentifizierten Lesezugriff eine vollständige Kompromittierung wird, wenn Secrets und SSH-Schlüssel neben der Anwendung liegen. Der maximale CVSS-Wert und die bestätigte aktive Ausnutzung machen sofortiges Patchen zur einzig verlässlichen Reaktion — Zugriffskontrolle ist hier nur eine Notlösung für die Zeit bis zum Update.
Quellen
Ich prüfe Ihre GitLab-Self-Managed-Instanzen auf Patch-Stand, härte Netzwerk- und Zugriffslogik um CI/CD-Systeme und begleite Sie bei Incident-Analyse nach möglicher Ausnutzung.
Patch-Audit, Log-Auswertung auf Kompromittierungsindizien, Härtung von Reverse-Proxy- und Netzwerkzugriff für GitLab-Self-Managed sowie angrenzende CI/CD-Komponenten.
Plattform-Betrieb statt Beratung auf Papier: Ich prüfe, patche und härte Ihre Infrastruktur laufend.