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. Betroffen sind laut GitLab 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". Geschlossen ist die Lücke mit den Versionen 19.1.8, 19.2.6 und 19.3.2.

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 Release Notes auflistet:

• 18.7 bis vor 19.1.8
• 19.2 bis vor 19.2.6
• 19.3 bis vor 19.3.2

Die Fixversionen sind 19.1.8, 19.2.6 und 19.3.2. 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 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.