Wie gefährlich ist die GitLab-Lücke CVE-2026-85706?

GitLab-Lücke CVE-2026-85706: Eine Anfrage liest jede Datei vom Server

Markus Seyfferth

Autor Dr. Web

14. September 2026

3 Min. Lesezeit

Eine einzige Anfrage an die Commits-API reicht: Ein nicht angemeldeter Angreifer liest damit beliebige Dateien vom GitLab-Server, darunter Zugangsdaten und Konfigurationsgeheimnisse. Die Schwachstelle CVE-2026-85706 trägt den CVSS-Höchstwert 10,0. Schon einen Tag nach dem Patch tauchten die ersten Angriffe auf. Selbst gehostete Instanzen sollten heute patchen und die dabei offengelegten Geheimnisse danach neu setzen.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Am 11. September, keine 24 Stunden nach GitLabs Sicherheitsupdate, registrierten Sicherheitsforscher die ersten automatisierten Angriffe auf die GitLab-Lücke CVE-2026-85706. Der Fehler sitzt in der Repository-Commits-API und lässt sich ganz ohne Anmeldung auslösen. Für Unternehmen, die ihre Code-Basis auf einer eigenen GitLab-Instanz verwalten, zählt jetzt jede Stunde.

Das Wichtigste in Kürze

CVE-2026-85706 erreicht den CVSS-Höchstwert 10,0 und erlaubt unangemeldeten Zugriff auf beliebige Serverdateien.
Die Schwachstelle steckt in der Repository-Commits-API; eine präparierte Anfrage genügt, sobald mindestens ein öffentliches Projekt existiert.
GitLab.com und Dedicated sind bereits abgesichert, das Risiko trägt die selbst gehostete Community und Enterprise Edition.
Die CISA führt den Fehler seit dem 11. September als aktiv ausgenutzt, US-Bundesbehörden mussten bis zum 14. September patchen.

Wie funktioniert der Angriff?

Schließfächer mit teilweise offenen Türen, davor ein großer Schlüssel, ein Fach trägt den Text 'OFFEN' — Pfad-Traversal-Fehler in Repository-Commits-API ermöglicht unbefugten Dateizugriff auf Servern mit öffentlichen Projekten

Im Kern ist die Lücke ein Pfad-Traversal-Fehler. Eine fehlende Pfadbegrenzung und eine ausgehebelte Authentifizierung in der Repository-Commits-API erlauben es, über den Endpunkt der Commits-Anfrage mit einem präparierten Datei-Pfad aus dem Projektverzeichnis auszubrechen und beliebige Dateien des Servers zu lesen.^[1] Eine Bedingung genügt dafür: mindestens ein öffentliches Projekt auf der Instanz.

Damit greift der Angriff ohne Anmeldung. Ein Angreifer mit der passenden Anfrage liest Logdateien und Konfigurationsdateien aus und findet darin Zugangsdaten, Tokens und weitere Geheimnisse. Aus einem einzigen gelesenen Token wird schnell ein vollwertiger Zugang. Genau deshalb reicht Patchen allein nicht.

Ein Einzelfall oder ein Muster?

Ein Muster. Kritische Lücken in Entwickler- und Infrastruktur-Software landen zunehmend binnen Stunden im Visier automatisierter Scanner. Die Sicherheitsfirma watchTowr registrierte die ersten Angriffe auf CVE-2026-85706 bereits am 11. September um 06:00 UTC, also keinen vollen Tag nach der Veröffentlichung des Patches.^[1]

Dasselbe Drehbuch wiederholt sich quer durch die Branche. GitLab stand zuletzt schon wegen einer Lücke in der GraphQL-Schnittstelle im Fokus. Die aktiv ausgenutzte Langflow-Schwachstelle und mehrere Cisco- und Fortinet-Fehler stehen längst in CISAs Katalog. Ein CVSS-Wert von 10,0 ohne nötige Anmeldung ist die Kombination, die Massenscans zuverlässig anzieht.

Eine selbst gehostete Code-Basis bedeutet Kontrolle und Verantwortung im Doppelpack. CVE-2026-85706 zeigt, dass diese Rechnung nur mit einem Patch-Reflex im Stundentakt aufgeht.
— Michael Dobler, Herausgeber Dr. Web

Was müssen deutsche Betreiber jetzt tun?

Sofort patchen. Betroffen sind ausschließlich selbst gehostete Instanzen der Community und Enterprise Edition; GitLab.com und Dedicated hat der Anbieter bereits abgesichert. Die Versionen 19.1.8, 19.2.6 und 19.3.2 schließen die Lücke. Nach dem Update gehört jedes Geheimnis rotiert, das ein Angreifer gelesen haben könnte, denn der Patch entzieht kein bereits abgeflossenes Token. Die CISA führt CVE-2026-85706 seit dem 11. September als aktiv ausgenutzt.^[2]

Für viele Unternehmen wird ein erfolgreicher Zugriff zudem zum Meldefall. Seit Dezember 2025 fallen rund 29.500 deutsche Firmen unter das NIS2-Umsetzungsgesetz, das erhebliche Sicherheitsvorfälle binnen 24 Stunden an das BSI meldepflichtig macht. Lässt sich ein Datenabfluss nicht sicher ausschließen, gehören die Server-Logs auf verdächtige Anfragen an die Commits-Schnittstelle geprüft. Die Cybersecurity-Grundlagen liefern die Schritte für den Ernstfall.

GitLab-Lücke CVE-2026-85706 im Steckbrief

Eine Schwachstelle mit Höchstwertung, die ohne Anmeldung ganze Server ausliest

10,0

CVSS-Höchstwert, die kritischste Stufe der Skala

Anfrage genügt, ganz ohne Anmeldung am System

rettende Versionen: 19.1.8, 19.2.6 und 19.3.2

Vom Patch zum Angriff in Stunden

10.09.2026GitLab veröffentlicht die Patches für Community und Enterprise Edition.
11.09.2026Erste automatisierte Angriffe ab 06:00 UTC, keinen vollen Tag später.
11.09.2026Die CISA nimmt die Lücke in ihren Katalog aktiv ausgenutzter Schwachstellen auf.
14.09.2026Patch-Frist für die US-Bundesbehörden läuft ab.

FAQ: GitLab-Lücke CVE-2026-85706

Was ist die GitLab-Lücke CVE-2026-85706?

CVE-2026-85706 ist eine Pfad-Traversal-Schwachstelle in der Repository-Commits-API von GitLab mit dem CVSS-Höchstwert 10,0. Ein nicht angemeldeter Angreifer kann damit über eine einzelne Anfrage beliebige Dateien vom GitLab-Server lesen, sofern mindestens ein öffentliches Projekt existiert.

Welche GitLab-Versionen sind von CVE-2026-85706 betroffen?

Betroffen sind Community und Enterprise Edition von 18.7 bis vor 19.1.8, von 19.2 bis vor 19.2.6 sowie von 19.3 bis vor 19.3.2. Die Fehlerkorrektur steckt in den Versionen 19.1.8, 19.2.6 und 19.3.2, die GitLab am 10. September 2026 veröffentlicht hat.

Ist GitLab.com von der Sicherheitslücke betroffen?

Nein. GitLab.com und GitLab Dedicated sind laut Anbieter bereits abgesichert. Das Risiko trägt allein die selbst gehostete Community und Enterprise Edition, deren Betreiber das Update eigenständig einspielen müssen.

Wird CVE-2026-85706 bereits aktiv ausgenutzt?

Ja. Sicherheitsforscher von watchTowr registrierten die ersten automatisierten Angriffe am 11. September 2026 ab 06:00 UTC, keinen vollen Tag nach dem Patch. Die US-Behörde CISA führt die Lücke seit demselben Tag als aktiv ausgenutzt.

Wie schützen Sie Ihre GitLab-Instanz vor CVE-2026-85706?

Spielen Sie umgehend die Version 19.1.8, 19.2.6 oder 19.3.2 ein. Rotieren Sie danach alle Zugangsdaten und Tokens, die ein Angreifer gelesen haben könnte, denn der Patch entzieht keine bereits abgeflossenen Geheimnisse. Prüfen Sie zusätzlich die Server-Logs auf verdächtige Anfragen an die Commits-Schnittstelle.