Angreifer nutzen eine kritische Schwachstelle in GitLab aktiv aus. Die US-Sicherheitsbehörde CISA hat den Fehler mit der Kennung CVE-2026-85706 deshalb in ihren Katalog nachweislich ausgenutzter Schwachstellen aufgenommen. Die Path-Traversal-Lücke erreicht den maximalen CVSS-Wert von 10,0.
Betroffen sind ungepatchte Installationen von GitLab Community Edition und Enterprise Edition. Ein Angreifer benötigt weder ein Benutzerkonto noch andere Zugriffsrechte: Eine präparierte Anfrage an die Repository-Commits-API kann ausreichen, um beliebige Dateien und damit möglicherweise Zugangsdaten, Secrets oder andere sensible Informationen vom Server zu lesen. Für Betreiber ist deshalb nicht nur das Update entscheidend. Sie müssen auch prüfen, ob die Instanz vor dem Einspielen des Patches bereits angesprochen wurde.
Der Fehler liegt in der Repository-Commits-API
CVE-2026-85706 entsteht durch eine fehlende Durchsetzung der Authentifizierung in Verbindung mit einer unzureichenden Begrenzung von Dateipfaden. Betroffen ist die API für Repository-Commits. Durch manipulierte Pfadangaben kann eine Anfrage den vorgesehenen Bereich verlassen und auf Dateien zugreifen, die über die Schnittstelle nicht erreichbar sein sollten.
Angriffsweg bei CVE-2026-85706
Die Grafik zeigt, wie eine nicht authentifizierte Anfrage über die Repository-Commits-API und unzureichend begrenzte Dateipfade zum Lesen sensibler Serverdateien führen kann.
Das verschärft die Lage gegenüber Fehlern, die erst nach einer Anmeldung oder mit bestimmten Projektberechtigungen ausnutzbar sind. Hier ist keine Authentifizierung erforderlich. Ist eine verwundbare GitLab-Instanz aus dem Netz erreichbar, lässt sich die Schwachstelle grundsätzlich direkt ansprechen.
Das Sicherheitsunternehmen watchTowr berichtete am 11. September, bereits Anfragen gegen ungepatchte GitLab-Server im Internet zu beobachten. Nach Angaben der Forscher lässt sich der Dateizugriff mit einer einzelnen HTTP-Anfrage auslösen. Die beobachteten Scans belegen zunächst, dass Angreifer gezielt nach verwundbaren Systemen suchen. Unabhängig davon führt CISA die Lücke ausdrücklich als aktiv ausgenutzt. Öffentlich bekannte Angaben zur Zahl erfolgreicher Kompromittierungen oder zu konkreten Opfern liegen in den bereitgestellten Informationen nicht vor.
Diese GitLab-Versionen benötigen ein Update
GitLab hat die Schwachstelle am 10. September 2026 geschlossen. Betroffen sind Community Edition und Enterprise Edition in allen Versionen vor 19.1.8, in der Versionsreihe 19.2 vor 19.2.6 sowie in der Reihe 19.3 vor 19.3.2.
Die korrigierten Versionen sind damit 19.1.8, 19.2.6 und 19.3.2. Betreiber sollten innerhalb des jeweils verwendeten Versionszweigs mindestens auf eine dieser Ausgaben aktualisieren. Eine vorgeschaltete Anmeldung schützt nicht, wenn die verwundbare API ohne Authentifizierung erreichbar bleibt.
Für US-Bundesbehörden setzte die Aufnahme in den Known Exploited Vulnerabilities Catalog eine kurze verbindliche Frist in Gang: Unter der Binding Operational Directive 26-04 mussten sie ihre Systeme bis zum 14. September 2026 absichern. Diese Vorgabe gilt nicht unmittelbar für private Unternehmen. CISA empfiehlt jedoch auch anderen Organisationen, Schwachstellen aus dem KEV-Katalog bei der Behebung zu priorisieren.
Ein Update beendet nicht automatisch einen möglichen Vorfall
Der Patch verhindert künftige Zugriffe über CVE-2026-85706. Er beantwortet aber nicht die Frage, ob ein Server zuvor bereits Dateien ausgeliefert hat. Gerade weil die Lücke ohne Anmeldung funktioniert und Angreifer kurz nach Veröffentlichung nach verwundbaren Instanzen suchten, sollten Betreiber Update und Untersuchung nicht als alternative Maßnahmen behandeln.
watchTowr empfiehlt, die HTTP-Protokolle nach POST-Anfragen an Pfade nach dem Muster /api/v4/projects/{id}/repository/commits/ zu durchsuchen. Besonders relevant sind Anfragen, die Parameter namens file.path enthalten. Solche Einträge sind ein Anlass für eine genauere Triage, aber für sich allein noch kein Beweis dafür, dass vertrauliche Dateien erfolgreich abgeflossen sind.
Die operative Reihenfolge ist dennoch klar: Zuerst müssen betroffene Instanzen auf einen korrigierten Stand gebracht oder bis dahin vom unkontrollierten Zugriff getrennt werden. Danach sollten Verantwortliche die Protokolle und den möglichen Zeitraum der Exposition untersuchen. Gibt es Anzeichen für einen erfolgreichen Zugriff, müssen potenziell lesbare Zugangsdaten und Secrets identifiziert und erneuert werden. Nur den Server zu aktualisieren, macht bereits offengelegte Schlüssel nicht wieder geheim.
Das Patch-Fenster ist auf einen Tag geschrumpft
Zwischen der Veröffentlichung der korrigierten GitLab-Versionen am 10. September und den von watchTowr gemeldeten Internet-Probes am 11. September lag nur ein Tag. Dieser Ablauf ist für selbstverwaltete Entwicklungsinfrastruktur besonders problematisch: GitLab ist nicht bloß eine weitere Webanwendung, sondern kann an einer Stelle sitzen, an der Quellcode, Automatisierung und Zugangsdaten für weitere Systeme zusammenlaufen.
Das bedeutet nicht, dass jede betroffene Instanz automatisch vollständig kompromittiert ist. Die konkrete Folge hängt davon ab, welche Dateien auf dem Server erreichbar waren, welche Secrets dort gespeichert wurden und ob ein Angreifer sie tatsächlich gelesen hat. Der maximale Schweregrad beschreibt das technische Potenzial der Lücke; die CISA-Einstufung ergänzt dazu die entscheidende Information, dass die Gefahr nicht mehr nur theoretisch ist.
Für Betreiber verschiebt sich damit die praktische Aufgabe vom gewöhnlichen Patch-Management zur Vorfallprüfung. Bei einer unauthentifizierten Lücke mit beobachteter Suche nach verwundbaren Servern ist der installierte Versionsstand nur die erste Frage. Die zweite lautet, wie lange die Instanz ungepatcht erreichbar war – und welche Zugangsdaten während dieses Fensters auf dem System lagen.
Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?
