GitLab Self-Managed aktualisieren (CVE-2026-110264)
Am 21. Oktober 2026 hat GitLab CVE-2026-110264 gepatcht, eine Lücke mit CVSS 10.0, die Codeausführung auf dem Server ohne Authentifizierung erlaubt und GitLab Self-Managed ab Version 7.0 aus dem Jahr 2014 betrifft. Neun Tage zuvor war CVE-2026-97229 behoben worden, ebenfalls 10.0. GitLab.com ist bereits aktualisiert; eigene Installationen liegen bei Ihnen.
Haben Sie diese Schwachstelle? Wir aktualisieren Ihr GitLab auf die korrigierte Version Ihres Zweigs, planen die Ausfallzeit, falls die Datenbankmigrationen sie erfordern, und prüfen Runner, Tokens und Logs.
$ sudo gitlab-rake gitlab:env:info | grep -A1 "GitLab information"GitLab informationVersion: 19.4.2-ee# 19.4.2 behebt CVE-2026-97229, nicht CVE-2026-110264$ cat /opt/gitlab/embedded/service/gitlab-rails/VERSION19.4.2-ee# Auch im Browser: https://ihr-gitlab/helpFür Zweig 19.4: auf 19.4.3 aktualisierenZwei Lücken mit CVSS 10.0 in neun Tagen
Wer am 12. Oktober wegen CVE-2026-97229 aktualisiert hat, muss es noch einmal tun: Jene Korrektur deckt CVE-2026-110264 nicht ab, die alle Versionen seit 2014 betrifft.
CVE-2026-110264 ist ein Integer-Overflow beim Kompilieren eines manipulierten regulären Ausdrucks in Onigmo, der Regex-Engine von Ruby, die GitLab mitliefert und in eigenen Paketen patcht. GitLab liefert sie seit 7.0 aus, deshalb reicht die Lücke so weit zurück. GitLab hat nicht erklärt, welche Bedingungen ein Angreifer braucht, eine Konfiguration schließt Sie also nicht aus, und eine vorübergehende Gegenmaßnahme gibt es nicht: Nur das Update behebt die Lücke.
Am 12. Oktober hatte GitLab CVE-2026-97229 behoben, ebenfalls CVSS 10.0: Codeausführung ohne Authentifizierung über einen manipulierten regulären Ausdruck in der CI/CD-Konfiguration, in den Versionen 19.2 bis 19.4 (behoben in 19.2.8, 19.3.5 und 19.4.2). Ein öffentlicher Proof of Concept existiert.
Stand 22. Oktober meldet GitLab keine Ausnutzung von CVE-2026-110264, und die Lücke steht nicht im KEV-Katalog der CISA. GitLab hat zwei Sigma-Regeln veröffentlicht, um nach Versuchen zu suchen: „Onigmo native worker crash“ und „Org mode render error burst“. GitLab-Dedicated-Instanzen ab 19.3.5-internal0 oder 19.4.2-internal0 haben die Korrektur bereits.
Quellen: The Hacker News: CVE-2026-110264 · The Hacker News: CVE-2026-97229
Korrigierte GitLab-Versionen
Gilt für GitLab CE und EE, das Sie selbst betreiben (Omnibus, Docker, Helm). Ist Ihre Version älter als die ihres Zweigs, sind Sie von CVE-2026-110264 betroffen.
| Wenn Sie haben | Update auf | Hinweis |
|---|---|---|
| 19.5 (vor 19.5.1) | 19.5.1 | |
| 19.4 (vor 19.4.3) | 19.4.3 | DB-Migrationen: Ausfallzeit bei einem Knoten |
| 19.3 (vor 19.3.6) | 19.3.6 | DB-Migrationen: Ausfallzeit bei einem Knoten |
| 19.2 (vor 19.2.9) | 19.2.9 | |
| 19.1 (vor 19.1.9) | 19.1.9 | |
| 19.0 (vor 19.0.10) | 19.0.10 | |
| 7.0 – 18.11 (vor 18.11.13) | 18.11.13 | Kann Zwischenversionen erfordern |
Prüfen Sie das
- Sie betreiben GitLab CE oder EE auf eigenem Server, in Docker oder in Ihrer Cloud, nicht auf GitLab.com.
- Die unter
/helpangezeigte Version ist älter als die Ihres Zweigs in der Tabelle. - Sie haben am 12. Oktober auf 19.2.8, 19.3.5 oder 19.4.2 aktualisiert: CVE-2026-110264 betrifft Sie weiterhin.
- Sie sind auf 18.10 oder älter: Ziel ist 18.11.13 oder eine 19.x, und GitLab verlangt auf dem Upgrade-Pfad Zwischenstopps.
- Ihre Instanz ist aus dem Internet erreichbar, auch wenn die Registrierung geschlossen ist: Die Lücke braucht kein Konto.
Keine vorübergehende Gegenmaßnahme
GitLab bietet für CVE-2026-110264 keinen Workaround. Vorbereiten lässt sich das Update selbst, damit es beim ersten Versuch klappt.
- 01 GitLab hat nicht gesagt, welche Bedingungen für die Ausnutzung nötig sind, also nimmt Sie keine Konfiguration aus dem Risiko.
- 02 Auf einem Server mit einem Knoten führen 19.4.3 und 19.3.6 während des Updates Datenbankmigrationen aus, und GitLab steht still, bis sie fertig sind.
- 03 Mit mehreren Knoten lässt sich das Update ohne Ausfallzeit nach GitLabs Zero-Downtime-Verfahren einspielen.
- 04 Bevor Sie etwas anfassen: Backup von Datenbank und Repositorys sowie von
gitlab-secrets.jsonundgitlab.rb, die das Standard-Backup nicht enthält.
Sieben Schritte, in dieser Reihenfolge
Wir wenden auf jedem Server dasselbe Verfahren an: zuerst klären, welche Version wo läuft, dann korrigieren und zum Schluss prüfen, ob vor dem Patch jemand eingedrungen ist.
Versionsinventar
Wir erfassen Version und Edition (CE oder EE), Installationsart (Omnibus, Docker, Helm), Zahl der Knoten, registrierte Runner und von wo aus die Instanz erreichbar ist.
Sofortmaßnahme
Ohne offiziellen Workaround lässt sich bis zum Wartungsfenster nur einschränken, wer die Instanz erreicht, etwa indem sie nur noch hinter dem VPN steht, wenn Ihr Team so arbeiten kann.
Update
Backup, Upgrade-Pfad mit den Zwischenstopps, die GitLab bei alten Versionen verlangt, und Sprung auf die korrigierte Version Ihres Zweigs. Erzwingen die Migrationen eine Ausfallzeit, legen wir den Zeitpunkt mit Ihnen fest.
Prüfung
Wir prüfen die Version unter /help, ob die Datenbankmigrationen abgeschlossen sind, ob die Runner sich verbinden und ob die Pipelines wieder durchlaufen.
Suche nach Kompromittierungsindikatoren
Wir wenden die von GitLab veröffentlichten Sigma-Regeln auf die Logs an und prüfen kürzlich angelegte Benutzer, persönliche Zugriffstokens und SSH-Schlüssel.
Rotation von Secrets, falls nötig
Gibt es Indikatoren, rotieren wir Runner-Tokens, persönliche und Deploy-Tokens, CI/CD-Variablen und die Schlüssel, mit denen die Pipelines deployen.
Beobachtung neuer Advisories
Wir halten Version, Upgrade-Pfad und GitLabs Patch-Kalender fest, damit das nächste Update nicht bei null beginnt.
Warum ein GitLab-Update schiefgeht
Ihr GitLab wurde seit Jahren nicht aktualisiert?
Kostenlose Beratung →Häufige Fragen zu CVE-2026-110264
Welche GitLab-Version behebt CVE-2026-110264?
Ich habe am 12. Oktober aktualisiert. Muss ich es noch einmal tun?
Ich nutze GitLab.com. Muss ich etwas tun?
Legt das Update GitLab lahm?
Gibt es eine Gegenmaßnahme, wenn ich heute nicht aktualisieren kann?
Sagen Sie uns, welches GitLab Sie betreiben
Mit Version, Installationsart und Zahl der Knoten nennen wir Ihnen den Upgrade-Pfad und sagen, ob eine Ausfallzeit nötig wird.
Erzählen Sie uns Ihre Herausforderung. Wir schlagen die Lösung vor.
Unverbindlich. Innerhalb von 24 Stunden erhalten Sie ein Angebot mit Umfang, Zeitplan und Budget. Ohne Kleingedrucktes.