GitLab-Sicherheitslücke CVE-2026-85706: Was Unternehmen mit eigener Instanz jetzt tun müssen

Wer eine eigene GitLab-Instanz betreibt, sollte diesen Text nicht auf morgen verschieben. Am 10. September 2026 hat GitLab eine Sicherheitslücke geschlossen, die auf der CVSS-Skala den höchstmöglichen Wert von 10.0 erreicht – und schon einen Tag später beobachteten Sicherheitsforscher erste Angriffsversuche in freier Wildbahn. Für ein Softwarehaus, eine IT-Abteilung oder ein Entwicklerteam, das den eigenen Quellcode auf einem selbst gehosteten GitLab verwaltet, ist das kein Randereignis, sondern ein Fall, der binnen Stunden von "betrifft uns theoretisch" zu "betrifft uns konkret" kippen kann.

Was die Lücke technisch bedeutet

Laut den Release Notes von GitLab (öffnet in neuem Tab) hat GitLab "an issue that, under certain conditions, an unauthenticated user could have read arbitrary files from the GitLab server due to improper path confinement and missing authentication enforcement in the repository commits API" behoben – zu deutsch: Ein Angreifer kann ohne jede Anmeldung beliebige Dateien vom Server auslesen, weil die Commits-API in der Repository-Verwaltung Pfadangaben nicht ausreichend prüft. Als betroffen nannte GitLab am 10. September 2026 zunächst alle Versionen von GitLab Community Edition (CE) und Enterprise Edition (EE) "from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2" und schloss die Lücke mit den Versionen 19.1.8, 19.2.6 und 19.3.2. Nachtrag vom 23. September 2026: Der betroffene Bereich reicht tatsächlich weiter zurück – Details und die zusätzlichen Fixversionen im Abschnitt "Wer patchen muss" unten.

Was in der Praxis auf dem Spiel steht, hat GitLab in derselben Ankündigung präzisiert: Neben der eigentlichen Pfad-Lücke (CVE-2026-85706, CVSS 10.0) wurde parallel eine zweite kritische Schwachstelle geschlossen, "an issue that, under certain conditions, could allow an authenticated user with Duo Chat access to obtain Advanced Search instance configurations and sensitive credentials" (CVE-2026-87719, CVSS 9.9). Beide Lücken werden mit denselben Patch-Versionen behoben.

Ein Git-Repository ist im Alltag mehr als Quellcode: Konfigurationsdateien, API-Schlüssel, Zugangsdaten in CI/CD-Variablen und interne Dokumentation liegen dort oft nebeneinander. Wer sich unautorisiert Zugriff auf solche Dateien verschafft, hat häufig genug Material für den nächsten, deutlich folgenreicheren Angriff in der Hand.

Wie schnell aus der Meldung ein aktiver Angriff wurde

Die Zeitlinie ist eng. Laut CISA (öffnet in neuem Tab) nahm die US-Cybersicherheitsbehörde CVE-2026-85706 bereits am 11. September 2026 – also einen Tag nach dem GitLab-Patch – in ihren "Known Exploited Vulnerabilities Catalog" auf, was laut CISA "based on evidence of active exploitation" geschieht. Die Sicherheitsfirma watchTowr bestätigt diese Beobachtung mit einem eigenen Zeitpunkt: Ihr Honeypot-Netzwerk "Attacker Eye" habe "behavioral probes for this vulnerability" registriert, wie watchTowr in seiner Analyse (öffnet in neuem Tab) schreibt, und stuft das Risiko einer breiten, wahllosen Ausnutzung als hoch ein: "watchTowr assesses with a high confidence that this vulnerability will rapidly transition to indiscriminate, in-the-wild exploitation given the low complexity of exploitation."

heise online berichtet (öffnet in neuem Tab) zusätzlich, dass CISA im selben Zeitraum vor aktiven Angriffen auf drei weitere Produkte gewarnt hat: zwei Schwachstellen im Repository-Manager JFrog Artifactory (CVE-2026-42016, CVSS 8.8, und CVE-2026-42018, CVSS 7.5) sowie eine Lücke in der Fernwartungssoftware ConnectWise ScreenConnect (CVE-2026-84869, CVSS 9.9), bei der laut heise "IT-Sicherheitsforscher von Huntress ... Wurm-artige Aktivitäten" beobachten. Der GitLab-Fall steht damit nicht isoliert, sondern reiht sich in eine Woche ein, in der mehrere weit verbreitete Entwickler-Werkzeuge gleichzeitig unter Beschuss standen.

Für die eigene Risikoeinschätzung ist eine Einschränkung wichtig: GitLab.com und GitLab Dedicated sind nach Angaben des Herstellers bereits serverseitig abgesichert, betroffen sind ausschließlich selbst gehostete (self-managed) Installationen.

Wie ernst die Lage inzwischen ist, zeigt eine Einschätzung gegenüber Dark Reading (öffnet in neuem Tab): Jake Knott, Head of Threat Intelligence bei watchTowr, berichtet dort, dass sich die Angriffe binnen weniger Tage von reinen Scans zu vollständiger Ausnutzung mit Datenabfluss entwickelt haben: "Over the weekend, we also observed threat actors dumping config files for secrets along with system SSH configurations for the victim system." Voraussetzung für einen erfolgreichen Angriff ist laut Knott mindestens ein öffentlich sichtbares Projekt auf der GitLab-Instanz – eine Konfiguration, die er als "probably a relatively common configuration" einstuft, weil Teams ein einzelnes öffentlich gestelltes Repository leicht übersehen. Laut Dark Reading ist CVE-2026-85706 zudem nicht die erste kritische GitLab-Lücke in diesem Zeitraum: Bereits im Vormonat sei eine GraphQL-Code-Injection-Schwachstelle (CVE-2026-19478) kurz nach ihrer Veröffentlichung aktiv ausgenutzt worden.

Wer patchen muss

Konkret betroffen sind selbst gehostete GitLab-Instanzen der Community und Enterprise Edition in folgenden Versionsständen, wie GitLab in den inzwischen aktualisierten Release Notes auflistet:

• 18.7 bis vor 18.11.12
• 19.0 bis vor 19.0.9
• 19.1 bis vor 19.1.8
• 19.2 bis vor 19.2.6
• 19.3 bis vor 19.3.2

Die Fixversionen sind 18.11.12, 19.0.9, 19.1.8, 19.2.6 und 19.3.2 – die beiden erstgenannten kamen erst nachträglich dazu. Am 10. September 2026 hatte GitLab zunächst nur für die Linien 19.1 bis 19.3 einen Fix veröffentlicht. Wer zu diesem Zeitpunkt noch eine ältere, selbst gehostete Version zwischen 18.7 und 18.11 oder die Linie 19.0 betrieb, fand damals keine passende Zielversion – obwohl auch diese Linien die Lücke enthielten. Laut den Release Notes von GitLab (öffnet in neuem Tab) wurde das am 23. September 2026 nachgeholt: "On September 23, 2026, we backported fixes for CVE-2026-85706 and CVE-2026-87719 to versions 19.0.9 and 18.11.12 of GitLab Community Edition (CE) and Enterprise Edition (EE). Self-managed GitLab administrators running older versions of GitLab CE and EE can now upgrade to these versions to apply these security fixes." Wer die erste Patch-Welle im September mangels passender Version ausgesetzt hat, sollte den eigenen Bestand jetzt also erneut prüfen und auf 18.11.12 beziehungsweise 19.0.9 aktualisieren.

Wer nicht mit Sicherheit weiß, ob im eigenen Haus noch irgendwo eine ältere, selbst gehostete GitLab-Instanz läuft – etwa aus einem früheren Projekt oder einem vergessenen Entwicklungsserver –, sollte das jetzt klären. Solche Alt-Installationen mit Internetanbindung gehören erfahrungsgemäß zu den Systemen, die bei Sicherheitsprüfungen am häufigsten übersehen werden.

Was jetzt konkret zu tun ist

1. Bestand klären. Prüfen Sie, ob und wo im Unternehmen selbst gehostete GitLab-Instanzen laufen – auch solche, die nicht mehr aktiv im Tagesgeschäft genutzt werden, aber noch erreichbar sind.
2. Sofort aktualisieren. GitLab empfiehlt in den Release Notes ausdrücklich, "all self-managed GitLab installations be upgraded to one of these versions immediately" – also 18.11.12, 19.0.9, 19.1.8, 19.2.6 oder 19.3.2, je nach eingesetzter Minor-Version.
3. Erreichbarkeit einschränken, wenn ein Update nicht sofort möglich ist. Eine öffentlich erreichbare, ungepatchte GitLab-Instanz sollte vorübergehend vom Netz genommen oder auf VPN- beziehungsweise IP-beschränkten Zugriff umgestellt werden.
4. Logs auf Auffälligkeiten prüfen. GitLab selbst hat laut den Release Notes "three threat detections" veröffentlicht, mit denen sich Ausnutzungsversuche der Lücke – etwa ungewöhnliche Zugriffe auf die Commits-API – in eigenen Logs erkennen lassen.
5. Zugangsdaten rotieren, wenn ein Zugriff nicht ausgeschlossen werden kann. Enthalten die eigenen Repositories Tokens, Zugangsdaten oder Secrets in Konfigurationsdateien oder CI/CD-Variablen, sollten diese vorsorglich erneuert werden, sobald ein unautorisierter Zugriff nicht sicher ausgeschlossen werden kann.

Warum dieser Fall über eine einzelne Lücke hinausweist

Der GitLab-Fall zeigt ein Muster, das sich bei kritischen Schwachstellen in weit verbreiteter Software wiederholt: Zwischen der Veröffentlichung eines Patches und den ersten beobachteten Angriffsversuchen liegt inzwischen oft nur noch ein einziger Tag. Wer Sicherheitsupdates nach einem festen Wartungsfenster einspielt, etwa einmal im Monat, verliert in solchen Fällen genau die Zeit, die für eine erfolgreiche Ausnutzung reicht.

Für Unternehmen, die eine selbst gehostete Entwicklungsplattform betreiben, ist das ein guter Anlass, den eigenen Patch-Prozess ehrlich zu prüfen: Gibt es eine Liste aller aus dem Internet erreichbaren internen Systeme? Und gibt es einen definierten Weg, wie eine kritische Warnung wie diese ohne tagelange Abstimmung in ein Update umgesetzt wird? Bei einer Lücke mit CVSS 10.0 und aktiver Ausnutzung binnen 24 Stunden ist das keine akademische Frage mehr.

Nachtrag vom 9. November 2026: Zwei weitere kritische Lücken, diesmal in der Ruby-Engine

Der GitLab-Fall vom September war kein Einzelfall. Im Oktober und November 2026 kamen zwei weitere Sicherheitslücken mit dem höchstmöglichen CVSS-Wert von 10.0 hinzu – CVE-2026-97229 und CVE-2026-110264 –, und laut einem Scan der Shadowserver Foundation, über den Golem.de berichtet (öffnet in neuem Tab), waren zum 1. November 2026 weltweit rund 10.925 online erreichbare GitLab-Instanzen für mindestens eine der beiden Lücken anfällig – fast ein Drittel aller von der Organisation erfassten rund 39.000 GitLab-Server. Etwa jede zehnte betroffene Instanz steht laut dem Bericht in Deutschland: konkret 1.060 der 10.925 anfälligen Systeme, alle davon für CVE-2026-110264 verwundbar.

Die Ursache liegt dieses Mal nicht direkt in GitLab, sondern in Onigmo, der regulären-Ausdrücke-Engine von Ruby, auf der GitLab aufbaut. Wie Ruby-Lang.org in der eigenen Sicherheitsmitteilung (öffnet in neuem Tab) erklärt, kann ein Angreifer durch speziell gestaltete reguläre Ausdrücke – etwa in der CI/CD-Konfiguration – Speicher beschädigen und daraus Schadcode auf dem Server ausführen, wenn GitLab Muster aus nicht vertrauenswürdiger Quelle kompiliert. Betroffen sind laut Ruby-Lang.org die Ruby-Versionen vor 3.3.13, 3.4.12 und 4.0.9. Die GitLab-eigenen Patches für CVE-2026-97229 liegen laut NVD-Eintrag (öffnet in neuem Tab) in den Versionen 19.2.8, 19.3.5 und 19.4.2, für CVE-2026-110264 laut den GitLab Release Notes (öffnet in neuem Tab) in 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 und 19.5.1.

Eine Besonderheit, die GitLab in seinen Release Notes ausdrücklich betont: Wer GitLab nicht über die offiziellen Linux-Pakete oder Container-Images betreibt, sondern mit einer eigenen Ruby-Laufzeitumgebung – etwa bei einer selbst kompilierten Installation oder einem angepassten Container-Image –, ist mit dem GitLab-Update allein nicht geschützt. Der Fix für CVE-2026-110264 steckt im Ruby-Patch, nicht im GitLab-Code (öffnet in neuem Tab), und ist nur in den offiziellen GitLab-Paketen enthalten. Wer eine eigene Ruby-Version einsetzt, muss Ruby separat auf 3.3.13, 3.4.12 oder 4.0.9 aktualisieren.

CVE-2026-97229 steht zudem im Known-Exploited-Vulnerabilities-Katalog der CISA (öffnet in neuem Tab), seit dem 29. Oktober 2026 mit einer von CISA gesetzten Frist zum 1. November – ein Hinweis darauf, dass die US-Behörde bereits aktive Ausnutzung beobachtet hat.

Was jetzt zusätzlich zu prüfen ist, wenn das September-Update bereits eingespielt wurde:

1. Erneut auf die aktuelle Patch-Version aktualisieren. Die im September genannten Versionen (18.11.12, 19.0.9, 19.1.8, 19.2.6, 19.3.2) schließen CVE-2026-97229 und CVE-2026-110264 nicht. Nötig sind mindestens 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 oder 19.5.1.
2. Eigene Ruby-Installationen gesondert prüfen. Wer GitLab nicht aus den offiziellen Paketen betreibt, muss Ruby unabhängig vom GitLab-Update aktualisieren.
3. Erreichbarkeit erneut einschränken, wenn ein Update nicht sofort möglich ist – dieselbe Empfehlung wie im September gilt auch für die neuen Lücken.