GitLab-Lücke durch Pfad-Traversal in CISA-KEV aufgenommen – dreitägige Frist für den Patch

GitLab fordert Administratoren selbstverwalteter Installationen auf, eine Schwachstelle mit maximalem Schweregrad zu beheben, über die beliebige Dateien über die API für Repository-Commits offengelegt werden können.

Die als CVE-2026-85706 erfasste Path-Traversal-Schwachstelle betrifft sowohl GitLab Community Edition als auch Enterprise Edition. Unter bestimmten Bedingungen kann ein nicht authentifizierter Angreifer die Schwachstelle aus der Ferne mit einer einzigen HTTP-Anfrage ausnutzen.

CISA nahm die Schwachstelle am 11. September 2026 in den Katalog der bekannten ausgenutzten Schwachstellen (Known Exploited Vulnerabilities, KEV) auf. US-Bundesbehörden müssen die Behebung bis zum 14. September 2026 abschließen – damit bleibt ein ungewöhnlich knappes Zeitfenster von drei Tagen.

GitLab erklärte, bislang keine Ausnutzung in freier Wildbahn bestätigt zu haben. Das Sicherheitsunternehmen watchTowr beobachtete jedoch Scans des gesamten Internets nach ungepatchten GitLab-Servern. Die Aufnahme in den KEV-Katalog bedeutet außerdem, dass Verteidiger die Schwachstelle als aktive Bedrohung und nicht als rein theoretische Schwäche behandeln sollten.

Nicht authentifizierter API-Zugriff kann Serverdateien offenlegen

CVE-2026-85706 wird durch eine unzureichende Pfadbegrenzung und eine fehlende Durchsetzung der Authentifizierung bei der über die GitLab API bereitgestellten Funktion für Repository-Commits verursacht. Die Schwachstelle ist als CWE-22 klassifiziert, also als unzureichende Beschränkung eines Pfadnamens auf ein begrenztes Verzeichnis.

Ein Angreifer kann die Verarbeitung von Dateipfaden am Endpunkt für Repository-Commits so manipulieren, dass der GitLab-Server auf Inhalte außerhalb des vorgesehenen Verzeichnisses zugreift. Dafür sind weder ein gültiges Konto noch eine Benutzerinteraktion erforderlich; der Angriff kann laut den vorliegenden Angaben mit einer einzigen Anfrage ausgeführt werden.

Bei erfolgreicher Ausnutzung können beliebige Dateien offengelegt werden, die der GitLab-Dienst in der jeweiligen Serverkonfiguration lesen darf. Mögliche Ziele sind:

• Konfigurationsdateien von Anwendungen und Infrastruktur
• Zugangsdaten und Zugriffstoken
• API-Schlüssel und andere Geheimnisse
• Proprietärer Quellcode
• Repository-Daten
• Dateien mit Informationen über angebundene Dienste

Die verfügbaren technischen Informationen belegen das Lesen beliebiger Dateien. Sie zeigen nicht, dass CVE-2026-85706 eigenständig die Ausführung von Code aus der Ferne oder die direkte Änderung von Serverdateien ermöglicht.

Die Schwachstelle hat einen CVSS-3.1-Score von 10,0 und den Vektor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. Diese Bewertung beschreibt einen über das Netzwerk erreichbaren Angriff mit geringer Komplexität, für den weder Berechtigungen noch eine Benutzerinteraktion erforderlich sind. Der dokumentierte Vektor weist eine hohe Auswirkung auf Vertraulichkeit und Integrität, aber keine Auswirkung auf die Verfügbarkeit aus.

Der Forscher „s3ntago“ meldete die Schwachstelle über GitLabs Bug-Bounty-Programm auf HackerOne.

Genau betroffene Versionen und sichere Zielversionen

Die Schwachstelle betrifft GitLab CE und EE in drei Versionsbereichen:

• Versionen ab 18.7 bis einschließlich 19.1.7
• Versionen ab 19.2 bis einschließlich 19.2.5
• Versionen ab 19.3 bis einschließlich 19.3.1

Betreiber sollten daher je nach eingesetztem Release-Zweig auf 19.1.8, 19.2.6 oder 19.3.2 aktualisieren.

In einigen Berichten wurde die Korrektur allgemeiner als für den 19.1-Zweig geltend beschrieben. Administratoren sollten 19.1.8 als maßgebliche behobene Version betrachten und nicht davon ausgehen, dass jede 19.1-Version sicher ist.

Die unmittelbare Gefährdung betrifft selbstverwaltete Installationen, insbesondere Server, die aus dem öffentlichen Internet erreichbar sind. GitLab.com lief bereits mit einer gepatchten Version, während GitLab-Dedicated-Kunden mitgeteilt wurde, dass sie nichts unternehmen müssten.

Organisationen sollten ihr Bereitstellungsmodell dennoch überprüfen, statt sich ausschließlich auf das GitLab-Branding eines internen Dienstes zu verlassen. Von Geschäftsbereichen, Entwicklungsteams, Tochtergesellschaften oder externen Dienstleistern betriebene selbst gehostete Instanzen können außerhalb zentraler Patch-Prozesse liegen.

CISA-Einstufung erhöht die Priorität der Reaktion

CISA nahm CVE-2026-85706 am 11. September 2026 in den KEV-Katalog auf und setzte für Bundesbehörden eine Frist zur Behebung bis zum 14. September 2026.

Die vorgeschriebene Reaktion verlangt von Behörden, die vom Anbieter bereitgestellten Gegenmaßnahmen umzusetzen und dabei BOD 26-04, „Prioritizing Security Updates Based on Risk“, sowie die forensischen Triage-Anforderungen von CISA einzuhalten. Behörden, die Cloud-Dienste nutzen, müssen die anwendbaren Bestimmungen von BOD 26-04 befolgen oder deren Nutzung einstellen, wenn keine wirksamen Gegenmaßnahmen verfügbar sind. Asset-Verantwortliche müssen außerdem die Erreichbarkeit aus dem Internet bewerten und die risikobasierten Patch-Anforderungen der Richtlinie erfüllen.

Bei den öffentlichen Aussagen zur Ausnutzung ist zu unterscheiden: GitLab hatte keinen bestätigten Sicherheitsvorfall festgestellt, während watchTowr Scans und Sondierungsversuche meldete, jedoch keine nachweislich erfolgreichen Angriffe. Gleichzeitig zeigt die Aufnahme in den KEV-Katalog, dass CISA die Kriterien für eine bekannte Ausnutzung als erfüllt ansieht.

Bislang wurden öffentlich weder ein Bedrohungsakteur noch eine Kampagne, ein betroffenes Unternehmen, eine schädliche IP-Adresse, eine Payload, ein User-Agent oder ein angezielter Dateipfad identifiziert. Das Fehlen dieser Details erschwert die Zuordnung, sollte die Behebung aber nicht verzögern.

Aufklärung des gesamten Internets geht häufig der Ausnutzung voraus, sobald der Endpunkt und die Struktur der Anfrage einer Schwachstelle bekannt sind. In diesem Fall senken die fehlende Authentifizierung und die Möglichkeit eines Angriffs mit nur einer Anfrage den operativen Aufwand für Angreifer.

Wonach Verteidiger suchen sollten

Administratoren sollten die GitLab-Anwendungsprotokolle sowie alle Protokolle von Reverse-Proxy, Load-Balancer, Web Application Firewall oder API-Gateway prüfen, die dem Dienst vorgeschaltet sind.

Das relevanteste Muster ist eine HTTP-POST-Anfrage an eine URI mit folgendem Aufbau:

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

Anfragen mit einem file.path-Parameter sollten genauer untersucht werden. Diese Kombination kann auf einen Ausnutzungsversuch hindeuten. Die verfügbaren Informationen reichen jedoch nicht aus, um jede passende Anfrage zweifelsfrei als schädlich einzustufen.

Konkrete Payload-Zeichenfolgen oder Traversal-Sequenzen wurden nicht veröffentlicht. Verteidiger sollten, soweit dies rechtlich und betrieblich möglich ist, vollständige Anfragedaten sichern, darunter Zeitstempel, Quelladressen, Header, Parameter, Antwortcodes und Antwortgrößen.

Wenn verdächtige Anfragen gefunden werden, sollten Incident-Responder ermitteln, auf welche Dateien das Dienstkonto von GitLab zugreifen konnte. Die Untersuchung sollte Konfigurationsverzeichnisse, Repository-Speicher, Umgebungsdateien, Integrationseinstellungen, Backups, Zugangsdaten, Token und Geheimnisse abdecken, die für den Zugriff auf externe Systeme verwendet werden.

Wenn die Hinweise für einen Zugriff auf beliebige Dateien sprechen, sollten die betroffenen Geheimnisse als offengelegt behandelt und ersetzt werden. Teams sollten außerdem die nachgelagerten Dienste überprüfen, die mit diesen Zugangsdaten erreichbar sind. Das Patchen schließt die Schwachstelle, macht jedoch bereits von einem Angreifer erlangte Daten nicht ungültig.

Eine zweite kritische Schwachstelle betrifft GitLab Enterprise Edition

Dieselben Sicherheitsupdates beheben auch CVE-2026-87719, eine separate Schwachstelle durch unsichere Deserialisierung in GitLab Enterprise Edition.

Für diese Schwachstelle ist ein authentifizierter Benutzer mit Zugriff auf Duo Chat erforderlich. Unter bestimmten Bedingungen kann der Benutzer ein manipuliertes GraphQL-Subscription-Argument übermitteln, das die erwartete Verarbeitung der Serialisierung umgeht und die Suche nach Serverobjekten auslöst.

Der daraus resultierende Zugriff kann Konfigurationen von Advanced-Search-Instanzen und vertrauliche Zugangsdaten offenlegen. Anders als CVE-2026-85706 erfordert diese Schwachstelle geringe Berechtigungen und ermöglicht keinen anonymen Angriff.

CVE-2026-87719 hat einen CVSS-3.1-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. Sie ist als CWE-502 klassifiziert, also als Deserialisierung nicht vertrauenswürdiger Daten.

Betroffene Enterprise-Edition-Versionen sind:

• Versionen ab 18.3 bis einschließlich 19.1.7
• Versionen ab 19.2 bis einschließlich 19.2.5
• Versionen ab 19.3 bis einschließlich 19.3.1

CVE-2026-87719 ist nicht im CISA-KEV-Katalog aufgeführt. Organisationen, die Duo Chat und Advanced Search einsetzen, sollten die Schwachstelle dennoch in ihre Überprüfung einbeziehen, insbesondere bei der Untersuchung verdächtiger authentifizierter Aktivitäten.

GitLab war wiederholt von serverseitigen Schwachstellen im KEV-Katalog betroffen

Der neue KEV-Eintrag folgt auf weitere GitLab-Schwachstellen, über die Angreifer mithilfe serverseitiger Funktionen auf Daten oder interne Ressourcen zugreifen konnten.

CVE-2023-2825 war eine weitere Path-Traversal-Schwachstelle mit einem CVSS-Score von 10,0, die auf GitLab CE/EE 16.0.0 beschränkt war. Sie ermöglichte das Lesen von Dateien ohne Authentifizierung, wenn sich ein Anhang in einem öffentlichen Projekt befand, das in mindestens fünf Gruppen verschachtelt war.

Zwei ältere Schwachstellen durch serverseitige Anfragen (Server-Side Request Forgery, SSRF) wurden 2026 ebenfalls in den KEV-Katalog aufgenommen. CVE-2021-39935, die die CI-Lint-API betraf, wurde am 3. Februar 2026 mit einer Frist für Bundesbehörden bis zum 24. Februar 2026 aufgenommen. CVE-2021-22175, bei der es um Webhook-Anfragen an interne Netzwerke ging, folgte am 18. Februar 2026; die Behebung war bis zum 11. März 2026 vorgeschrieben.

Bei CVE-2026-85706 ist die erforderliche Reaktion klar: Jede selbstverwaltete Instanz identifizieren, auf die behobene Version des jeweiligen Zweigs aktualisieren, den API-Datenverkehr prüfen und einen möglichen Datenzugriff untersuchen. Systeme mit Internetzugang sollten zuerst bearbeitet werden.