Kritische GitLab-Lücke zum Lesen von Dateien innerhalb eines Tages nach Bekanntgabe des Patches ausgenutzt

Bedrohungsakteure begannen bereits einen Tag, nachdem das Unternehmen Sicherheitsupdates angekündigt hatte, mit der Untersuchung einer kritischen GitLab-Schwachstelle. Das berichten Forscher, die die Ausnutzung der Lücke beobachten.

Die als CVE-2026-85706 geführte Schwachstelle ermöglicht es einem nicht authentifizierten Angreifer, beliebige Dateien von einem selbst gehosteten GitLab-Server zu lesen. Für die Ausnutzung genügt eine einzige manipulierte HTTP-Anfrage. Dadurch werden exponierte und nicht gepatchte Installationen zu lohnenden Zielen für automatisierte Scans.

CVE-2026-85706 hat einen CVSS-Score von 10 und ist bereits im Katalog der bekannten ausgenutzten Schwachstellen der US-amerikanischen Cybersecurity and Infrastructure Security Agency (CISA) verzeichnet. Die CISA nahm die Schwachstelle am 11. September 2026 auf und setzte Bundesbehörden eine Frist bis zum 14. September 2026, um betroffene Systeme zu beheben.

Das zugehörige GitLab-Release behebt 17 weitere Schwachstellen, darunter einen zweiten kritischen Fehler und sechs Schwachstellen mit hohem Schweregrad. Administratoren sollten daher das vollständige Update einspielen, anstatt den Vorfall als eng begrenzten Path-Traversal-Fehler zu behandeln.

Nicht authentifizierter Path-Traversal-Angriff erreicht Serverdateien

CVE-2026-85706 ist eine Path-Traversal-Schwachstelle in der GitLab-API für Repository-Commits. Eine unzureichende Einschränkung von Dateipfaden in Verbindung mit einer fehlenden Authentifizierungsprüfung ermöglicht es Anfragen, den vorgesehenen Pfad zu verlassen und auf Dateien an anderer Stelle des Servers zuzugreifen.

Ein gültiges GitLab-Konto ist nicht erforderlich. Der Angriff kann über eine einzige HTTP-Anfrage erfolgen.

Der CVSS-Vektor lautet CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. Dies beschreibt eine aus der Ferne ausnutzbare Schwachstelle mit geringer Angriffskomplexität, für deren Ausnutzung weder Berechtigungen noch Benutzerinteraktion erforderlich sind und die sich stark auf die Vertraulichkeit auswirkt.

Nach diesem Bewertungsvektor hat die Schwachstelle keine direkten Auswirkungen auf die Verfügbarkeit. Der Zugriff auf beliebige Dateien kann jedoch Informationen offenlegen, die nachfolgende Angriffe ermöglichen. Dateien auf einem GitLab-Host können Anwendungskonfigurationen, Zugangsdaten, Zugriffstoken, Quellcode, Integrationsgeheimnisse oder Informationen über verbundene Infrastrukturen enthalten.

Welche Folgen konkret entstehen, hängt davon ab, auf welche Dateien zugegriffen werden kann und wie die jeweilige Installation konfiguriert ist. Aus öffentlich zugänglichen Berichten geht weder hervor, welche Dateien bei den beobachteten Ausnutzungsversuchen abgerufen wurden, noch wurden bestätigte Folgeschäden bekannt, die sich auf diese Versuche zurückführen lassen.

WatchTowr beobachtete einen Tag nach der Ankündigung der Patches durch GitLab erste Angriffe aus dem Internet und rechnet mit einer breiteren Ausnutzung. Zwischen der Veröffentlichung der Schwachstelle, dem Reverse Engineering, dem Scanning und den versuchten Kompromittierungen liegt damit nur ein sehr kurzer Zeitraum.

Genau betroffene GitLab-CE- und -EE-Versionen

Die Schwachstelle betrifft selbst gehostete Installationen von GitLab Community Edition und Enterprise Edition in den folgenden Versionsbereichen:

• GitLab CE und EE ab 18.7 bis vor 19.1.8
• GitLab CE und EE ab 19.2 bis vor 19.2.6
• GitLab CE und EE ab 19.3 bis vor 19.3.2

Administratoren sollten auf das für den eingesetzten Versionszweig passende korrigierte Release aktualisieren:

• 19.1.8 oder höher
• 19.2.6 oder höher
• 19.3.2 oder höher

Organisationen, die ältere oder separat gepflegte Versionszweige einsetzen, sollten das entsprechende vom Anbieter unterstützte korrigierte Release beziehen. Für cloud-spezifische betroffene Versionen oder Schutzmaßnahmen wurden keine Angaben veröffentlicht.

Selbst gehostete, aus dem Internet erreichbare Instanzen sind dem unmittelbarsten Scanrisiko ausgesetzt. Die interne Angriffsfläche sollte jedoch ebenfalls nicht außer Acht gelassen werden. Ein Angreifer, der bereits Zugriff auf ein Unternehmensnetzwerk hat, könnte einen intern erreichbaren GitLab-Server mit derselben nicht authentifizierten Anfrage angreifen.

GitLab-Systeme nehmen in Entwicklungsumgebungen zudem eine besonders sensible Position ein. Sie sind häufig mit Runnern, Deployment-Plattformen, Registries, Identitätsanbietern, Ticketsystemen und Cloud-Infrastrukturen verbunden. Der Zugriff auf Dateien auf dem Host könnte daher Zugangsdaten offenlegen, deren Reichweite über GitLab selbst hinausgeht.

Loganalysen können Ausnutzungsversuche aufdecken

GitLab-Administratoren sollten HTTP-Logs auf POST-Anfragen an die API für Repository-Commits prüfen:

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

Anfragen mit einem file.path-Parameter sollten untersucht werden, da sie Ausnutzungsversuche gegen CVE-2026-85706 darstellen können.

Dieses Muster allein sollte jedoch nicht automatisch als Beleg für eine Kompromittierung gewertet werden. Untersucher sollten passende Anfragen mit Quell-IP-Adressen, Zeitstempeln, Antwortcodes, ungewöhnlichen Dateizugriffen, Kontoaktivitäten und nachfolgenden Änderungen an Repositories oder Pipelines abgleichen.

Eine Untersuchung sollte außerdem Folgendes umfassen:

• Repository-Commits und Änderungen im Zeitraum rund um die verdächtige Anfrage
• Zugriffe auf CI/CD-Variablen und Projektgeheimnisse
• Pipeline-Definitionen und kürzlich gestartete Jobs
• Aktivitäten der Runner und unerwartete Build-Vorgänge
• Deploy Keys, persönliche oder projektbezogene Zugriffstoken und Integrationen
• Änderungen an Benutzern, Berechtigungen, Webhooks oder geschützten Branches
• Neu erstellte oder veränderte Build-Artefakte
• Authentifizierungen mit auf dem GitLab-Host gespeicherten Zugangsdaten
• Aktivitäten in nachgelagerten Deployment- und Paketumgebungen

Möglicherweise offengelegte Zugangsdaten und Geheimnisse sollten ausgetauscht werden. Die Teams sollten Pipeline-Definitionen validieren und sensible Artefakte aus vertrauenswürdigen Quellständen neu erstellen, wenn eine Kompromittierung nicht ausgeschlossen werden kann.

Das Einspielen des Patches schließt die bekannte Schwachstelle, entfernt jedoch keinen Angreifer, der bereits Zugangsdaten erlangt oder Entwicklungsressourcen manipuliert hat. Systeme mit verdächtigen Anfragen benötigen zusätzlich zum Upgrade eine forensische Untersuchung.

CISA setzt für Bundesbehörden den 14. September als Frist

Die CISA nahm CVE-2026-85706 am 11. September 2026 in ihren KEV-Katalog auf. Die Aufnahme bestätigt, dass die Schwachstelle außerhalb kontrollierter Forschungsumgebungen ausgenutzt wird, und macht aus einem theoretischen Risiko eine aktive betriebliche Priorität.

US-Bundesbehörden müssen die Behebung bis zum 14. September 2026 abschließen.

Die CISA verpflichtet betroffene Organisationen, die Abhilfemaßnahmen des Anbieters umzusetzen und dabei die Vorgaben des BOD 26-04 zur risikobasierten Priorisierung von Sicherheitsupdates einzuhalten. Die Behörden müssen außerdem die Anforderungen der CISA zur forensischen Triage befolgen.

Für Cloud-Dienste sollen Organisationen die geltenden Vorgaben des BOD 26-04 befolgen oder die Nutzung einstellen, wenn keine wirksamen Schutzmaßnahmen verfügbar sind. Jeder Beteiligte bleibt dafür verantwortlich, die Erreichbarkeit eines Assets aus dem Internet zu bewerten und die jeweils geltenden Anforderungen an die Behebung umzusetzen.

Eine Umgehungslösung mit gleichwertigem Schutz ist nicht bekannt. Die sofortige Installation des korrigierten GitLab-Releases ist daher die wichtigste Schutzmaßnahme.

Das Update behebt eine weitere kritische GitLab-Schwachstelle

Dasselbe Sicherheitsrelease behebt CVE-2026-87719, eine Schwachstelle durch unsichere Deserialisierung im GraphQL-Subscription-Serializer von GitLab.

Sie hat einen CVSS-Score von 9,9 und den Vektor CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Anders als bei CVE-2026-85706 sind für die Ausnutzung geringe Berechtigungen erforderlich. Die möglichen Auswirkungen betreffen jedoch Vertraulichkeit, Integrität und Verfügbarkeit.

Ein Angreifer könnte Zugriff auf Konfigurationen der Advanced-Search-Instanz und auf sensible Zugangsdaten erlangen. Die GitLab-CE- und -EE-Versionen 19.1.8, 19.2.6 und 19.3.2 beheben diese Schwachstelle.

Das Release behebt außerdem sechs Schwachstellen mit hohem Schweregrad, die unter anderem Remote Code Execution, den Zugriff auf geschützte CI/CD-Variablen, Cross-Site-Scripting oder Denial-of-Service ermöglichen können. Einzelheiten zu den übrigen behobenen Fehlern und allen betroffenen Versionsbereichen liegen hier nicht vor.

Das vollständige Release einzuspielen, ist entscheidend. Ein System, das nur gegen den Path-Traversal-Angriffsweg gepatcht wurde, könnte über eine der anderen korrigierten Komponenten weiterhin angreifbar sein.

Schnelle Ausnutzung folgt auf einen früheren GitLab-Fall

Die aktuelle Aktivität ist nicht der einzige Fall, in dem GitLab zuletzt nahezu unmittelbar ausgenutzt wurde. Forscher beobachteten zuvor schnelle Angriffe auf CVE-2026-19478, eine kritische GraphQL-Code-Injection-Schwachstelle.

CVE-2026-19478 hat einen CVSS-Score von 9,4 und ist als CWE-94 klassifiziert. Unter bestimmten Bedingungen konnte ein nicht authentifizierter Angreifer eine GraphQL-Direktive missbrauchen, um öffentliche Projekte und Benutzerdaten aus der Ferne zu ändern oder zu löschen.

Die betroffenen Versionsbereiche waren:

• GitLab CE und EE ab 18.2 bis vor 18.11.11
• ab 19.0 bis vor 19.0.8
• ab 19.1 bis vor 19.1.6
• ab 19.2 bis vor 19.2.4

Das wiederholte Auftreten zeigt, wie schnell Angreifer GitLab-Schwachstellen operationalisieren können, insbesondere wenn diese ohne Authentifizierung erreichbar sind. Entwicklungsplattformen vereinen wertvollen Code, Geheimnisse und Automatisierungssteuerungen an einem Ort.

Administratoren sollten CVE-2026-85706 umgehend beheben, relevante Logs sichern und verdächtigen Datenverkehr zur Repository-Commits-API untersuchen. Jeder Hinweis auf Dateizugriffe sollte den Austausch von Zugangsdaten sowie eine umfassendere Prüfung von Pipelines, Runnern, Integrationen, Artefakten und nachgelagerten Deployments auslösen.