GitLab Sicherheitslücke CVE-2026-110264: Kritisches Update für eigene Server

Ein Git-Server läuft im Hintergrund, verwaltet Quellcode, CI/CD-Pipelines und oft auch Zugangsdaten für Deployments. Genau deshalb ist eine neue Warnung von GitLab für Administratoren besonders ernst: Am 21. Oktober 2026 veröffentlichte der Hersteller ein außerplanmäßiges Sicherheitsupdate gegen eine Schwachstelle mit dem maximalen CVSS-Wert 10,0. Betroffen sind selbst betriebene GitLab-Instanzen – vom kleinen Homeserver bis zur Unternehmensplattform.

Die Kennung lautet CVE-2026-110264. Nach Angaben des Herstellers könnte ein Angreifer unter bestimmten Bedingungen ohne Anmeldung eigenen Code auf einem verwundbaren GitLab-Server ausführen. Besonders ungewöhnlich ist die Reichweite: Die betroffenen Versionen reichen bis GitLab 7.0 aus dem Jahr 2014 zurück. Wer Anfang Oktober bereits gepatcht hat, muss deshalb erneut prüfen.

Hier findest du die bestätigten Fakten, die tatsächlich betroffenen Versionen und einen kontrollierten Update-Weg für Linux und Docker. Stand der Recherche: 25. Oktober 2026. Die Hinweise ersetzen keine individuelle Prüfung der eigenen Installation.

GitLab Sicherheitslücke CVE-2026-110264: Was ist bestätigt?

GitLab beschreibt einen Integer Overflow im Compiler für reguläre Ausdrücke. Vereinfacht gesagt kann eine speziell gestaltete Zeichenfolge bei der Verarbeitung einen Zahlenüberlauf auslösen. Unter bestimmten, vom Hersteller nicht näher veröffentlichten Bedingungen kann daraus eine Remote Code Execution (RCE) entstehen – also das Ausführen von Programmcode auf dem Server aus der Ferne.

Die offizielle Einstufung lautet „Critical“ mit CVSS 10,0. Die Bewertung berücksichtigt unter anderem die mögliche Ausnutzung über das Netzwerk ohne Anmeldung und ohne Interaktion eines Opfers. Daraus folgt aber nicht, dass jede öffentlich erreichbare Instanz bereits angegriffen wurde oder dass der Angriffsweg in jeder Konfiguration identisch ist. GitLab hat die Voraussetzungen bewusst nicht im Detail veröffentlicht.

Wer ist betroffen – und welche GitLab-Versionen sind sicher?

Betroffen sind GitLab Community Edition (CE) und Enterprise Edition (EE) in selbst verwalteten Installationen. GitLab.com ist nach Herstellerangaben bereits gepatcht. Auch entsprechend aktualisierte GitLab-Dedicated-Umgebungen sind abgedeckt; wer GitLab selbst auf einer VM, einem dedizierten Linux-Server, in Docker oder in Kubernetes betreibt, muss dagegen seine eigene Version kontrollieren.

Die korrigierten Versionsstände lauten: 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 und 19.5.1. In jeder dieser Versionslinien sind ältere Patchstände verwundbar. Die Schwachstelle betrifft außerdem die historischen Versionen ab 7.0 bis vor 18.11.13. Wer auf einem sehr alten Stand festhängt, sollte den offiziell vorgesehenen Upgrade-Pfad planen, statt blind mehrere Hauptversionen zu überspringen.

Wichtig: Eine Versionsnummer ist nur dann aussagekräftig, wenn du sie mit der passenden Release-Linie vergleichst. 19.4.2 ist beispielsweise nicht durch dieses neue Update geschützt; 19.4.3 ist der korrigierte Patchstand. Für neue Installationen ist grundsätzlich die aktuell unterstützte, vollständig gepatchte Version die bessere Wahl.

Warum dieses GitLab-Update besonders dringend ist

Auf einem GitLab-Server liegen nicht nur Repositorys. Je nach Einrichtung verwaltet er CI/CD-Variablen, Deploy-Schlüssel, Zugriffstoken und Verbindungen zu Container-Registrys oder Produktionssystemen. Ein erfolgreicher Einbruch könnte deshalb Auswirkungen über den eigentlichen GitLab-Dienst hinaus haben. Wie groß der Schaden wäre, hängt von den tatsächlich vorhandenen Rechten und Geheimnissen ab.

GitLab hat zwei Erkennungsregeln veröffentlicht, die auffällige Ereignisse rund um den Regex-Compiler und das Rendering untersuchen: „Onigmo native worker crash“ und „Org mode render error burst“. Solche Hinweise können bei der Auswertung von Logs helfen. Sie ersetzen weder ein Sicherheitsupdate noch beweisen sie für sich allein einen erfolgreichen Angriff.

Eine bestätigte, flächendeckende Ausnutzung der konkreten CVE-2026-110264 lässt sich aus der Herstellerwarnung nicht ableiten. Bei einer kritischen, potenziell ohne Anmeldung ausnutzbaren Serverlücke sollte die Patch-Entscheidung trotzdem nicht davon abhängen, ob bereits öffentliche Opferberichte vorliegen.

GitLab-Version prüfen: So startest du den Sicherheitscheck

Prüfe zuerst, welche Edition und welcher Versionsstand tatsächlich laufen. Bei einer klassischen Linux-Paketinstallation kannst du die GitLab-Umgebungsinformationen abfragen. In Docker muss der Befehl im richtigen Container ausgeführt werden; ersetze den Containernamen durch den Namen deiner Installation.

sudo gitlab-rake gitlab:env:info

# Bei Docker, Containername anpassen:
docker exec gitlab gitlab-rake gitlab:env:info

Vergleiche die angezeigte Version mit den oben genannten korrigierten Patchständen. Notiere zusätzlich die Installationsart, den Speicherort der Konfiguration und den Backup-Status. Bei produktiven Instanzen solltest du CI/CD-Jobs und Wartungsfenster berücksichtigen. Ein ungetestetes Upgrade kann laufende Pipelines unterbrechen.

Vorbereitung: Versionsstand, Backup und Upgrade-Pfad

Ermittle zunächst die aktuelle Version mit gitlab-rake gitlab:env:info oder bei Docker mit docker exec gitlab gitlab-rake gitlab:env:info. Prüfe die Zielversion anhand der Patchstände weiter oben. Bei älteren Hauptversionen sind Upgrade-Zwischenstationen und abgeschlossene Hintergrundmigrationen erforderlich; führe niemals unkontrolliert einen direkten Sprung von einem jahrealten Release auf 19.5.1 durch.

Erstelle vor jedem Versionswechsel ein GitLab-Anwendungsbackup. Sichere danach die Konfiguration und insbesondere gitlab-secrets.json getrennt. Bewahre die Sicherungen außerhalb des zu aktualisierenden Servers auf und prüfe, ob genügend freier Speicher vorhanden ist.

sudo gitlab-backup create

# Nur bei Linux-Paketinstallation: Konfiguration separat sichern
sudo gitlab-ctl backup-etc

Wichtig: Das GitLab-Anwendungsbackup enthält nicht automatisch sämtliche Konfigurationsdateien, TLS-Zertifikate oder extern gespeicherte Daten. Prüfe auch Datenbanken, Objektspeicher, Container-Volumes und externe Registrys entsprechend deiner Installation. Ein Restore muss zur passenden GitLab-Version und Edition erfolgen.

GitLab Sicherheitsupdate unter Debian und Ubuntu installieren

Vor einem Update gehören ein vollständiges Backup, die Sicherung der GitLab-Secrets und ein geprüfter Upgrade-Pfad auf die To-do-Liste. Bei größeren Versionssprüngen können vorgeschriebene Zwischenversionen und Hintergrundmigrationen nötig sein. Ein Paketmanager-Befehl allein ist daher kein universeller Upgrade-Plan.

Für eine Linux-Paketinstallation über die offiziellen GitLab-Repositories sehen die grundlegenden Befehle so aus. Installiere nur die zur Edition und zum Upgrade-Pfad passende Zielversion; die Befehle sind nur Beispiele für Installationen, die bereits auf dem 19.5-Zweig laufen und laut Upgrade-Pfad direkt auf 19.5.1 wechseln dürfen.

# Nur für Instanzen auf dem 19.5-Zweig, nach Backup und Upgrade-Prüfung:
sudo apt update
sudo apt install gitlab-ee=19.5.1-ee.0

# Bei Community Edition stattdessen:
sudo apt install gitlab-ce=19.5.1-ce.0

Anschließend kontrollierst du den Dienstestatus und die GitLab-Gesundheitsprüfung. Plane genügend Zeit ein, bis Datenbankmigrationen und Hintergrundaufgaben abgeschlossen sind. Falls deine Installation bereits über den neuesten unterstützten Zweig läuft, ist ein reguläres Update auf den aktuellen Patchstand meist einfacher als der Wechsel von einer sehr alten Version.

sudo gitlab-ctl status
sudo gitlab-rake gitlab:check SANITIZE=true

Nach dem Paketupdate: Öffne die GitLab-Weboberfläche und kontrolliere Admin-Bereich, Projekte, Repository-Zugriff und eine ungefährliche Test-Pipeline. Prüfe, ob der Versionsstand tatsächlich auf einer korrigierten Patchversion liegt. Kontrolliere zusätzlich den Dienstestatus und die Ausgabe von gitlab:check. Bei Fehlermeldungen sichere Logs und behebe zunächst die Ursache, statt weitere Versionssprünge anzustoßen.

GitLab in Docker Compose aktualisieren – ohne die Daten zu verlieren

Auch bei Docker liegt die eigentliche GitLab-Installation nicht einfach nur im Container-Image. Die Daten, Konfiguration und Secrets müssen über persistente Volumes gesichert sein. Vor dem Austausch des Images solltest du ein GitLab-Backup anlegen und die Sicherung der Secrets separat prüfen. Für große Versionssprünge gelten dieselben vorgeschriebenen Upgrade-Stationen wie bei anderen Installationsarten.

Passe in deiner Compose-Datei zuerst das GitLab-Image auf einen tatsächlich korrigierten, zu deiner Edition passenden Tag an, beispielsweise gitlab/gitlab-ee:19.5.1-ee.0, wenn dein Upgrade-Pfad direkt dorthin führt. Danach führst du im richtigen Compose-Projekt die Aktualisierung aus:

docker compose pull
docker compose up -d
docker compose ps

Kontrolliere danach die GitLab-Oberfläche, die Logs, die Versionsanzeige und mindestens eine Test-Pipeline. Ein Docker-Image-Update ohne funktionierende Backups oder ohne korrekt eingebundene Volumes ist keine sichere Wartungsstrategie. Bei einem Fehlschlag solltest du nicht einfach auf ein altes Image zurückschalten: Datenbankschemata können bereits migriert worden sein.

Docker-Checkliste vor dem Neustart

1. Im Compose-Projekt das aktuell laufende Image und die eingebundenen Volumes dokumentieren. 2. Das GitLab-Anwendungsbackup innerhalb des Containers ausführen und die Sicherung außerhalb des Containers ablegen. 3. Konfiguration und Secrets aus den persistenten Volumes separat sichern. 4. Den passenden gepatchten Image-Tag in compose.yaml eintragen. 5. Erst dann Image laden und Container kontrolliert neu erstellen. 6. Version, Logs, Weboberfläche und Test-Pipeline überprüfen.

docker compose ps
docker compose images

# Beispiel bei Containername gitlab:
docker exec gitlab gitlab-backup create

# Nach Prüfung des neuen Image-Tags in compose.yaml:
docker compose pull
docker compose up -d
docker compose logs --tail=100 gitlab

Hinweis: Der Service-Name im letzten Befehl muss zum Eintrag in deiner Compose-Datei passen. Ein GitLab-Backup ersetzt kein Volume-Backup. Prüfe bei älteren Installationen vorab notwendige Upgrade-Stopps und Datenbankmigrationen; ein bloßes Zurückwechseln des Docker-Images ist nach einer Migration kein sicherer Rollback.

Verdacht auf Angriff: Erst sichern, dann untersuchen

Wenn dein GitLab ungewöhnliche Abstürze, unerwartete Jobs, neue Zugangstoken oder auffällige ausgehende Verbindungen zeigt, dokumentiere zunächst den Zustand. Sichere relevante Logs und ziehe bei produktiven Systemen einen Incident-Response-Prozess hinzu. Ein überhasteter Neustart kann wichtige flüchtige Spuren beseitigen. Die von GitLab bereitgestellten Erkennungsregeln sind ein guter Ausgangspunkt, aber keine vollständige forensische Prüfung.

Prüfe nach einer möglichen Kompromittierung nicht nur den GitLab-Server selbst, sondern auch die daran angebundenen Deploy-Ziele. Falls Zugangsdaten betroffen sein könnten, müssen Tokens, Schlüssel und Secrets gezielt erneuert werden. Welche Maßnahmen nötig sind, hängt von den festgestellten Zugriffsrechten und dem tatsächlichen Vorfall ab.

Konkrete Sofortmaßnahmen bei Verdacht auf einen Einbruch

Begrenze den externen Zugriff auf die betroffene Instanz, ohne vorhandene Beweise zu vernichten. Sichere GitLab-, Reverse-Proxy-, Betriebssystem- und Container-Logs mit Zeitstempeln. Dokumentiere neue Benutzer, Tokens, SSH-Schlüssel, CI/CD-Variablen, Runner und ungewöhnliche Pipeline-Ausführungen. Prüfe die verbundenen Deploy-Ziele und Container-Registrys. Falls ein Zugriff nicht ausgeschlossen werden kann, rotiere kompromittierungsgefährdete Tokens und Secrets nach einem abgestimmten Wiederherstellungsplan. Ein Patch beseitigt die Schwachstelle, aber nicht automatisch eine bereits bestehende Kompromittierung.

Nicht verwechseln: GitLab hatte bereits am 12. Oktober eine kritische Lücke

Am 12. Oktober 2026 veröffentlichte GitLab bereits Updates gegen CVE-2026-97229, ebenfalls eine kritische Schwachstelle im Umfeld regulärer Ausdrücke. Die neue CVE-2026-110264 vom 21. Oktober ist jedoch eine andere Sicherheitslücke und betrifft zusätzlich sehr alte GitLab-Versionen. Wer am 12. Oktober aktualisiert hat, darf deshalb nicht automatisch davon ausgehen, jetzt geschützt zu sein.

Mein Fazit: Patchen statt auf Exploit-Meldungen warten

Für mich ist die Priorität klar: Wer GitLab selbst betreibt, sollte heute seine Version prüfen, den Backup- und Upgrade-Pfad klären und den passenden Sicherheitspatch zeitnah installieren. Die Kombination aus maximaler Risikobewertung, potenziell fehlender Anmeldung und einer ungewöhnlich langen Liste betroffener Versionen macht diese Warnung relevant – auch für kleine selbst gehostete Installationen.

Auf Luftpoet habe ich bereits gezeigt, wie schnell sich Sicherheitslagen bei selbst betriebenen Diensten ändern können. Wenn du weitere Server betreibst, helfen dir auch meine Beiträge zu den aktuellen PHP-Sicherheitslücken und zu Plex2Shell dabei, die eigene Wartungsroutine zu überprüfen. Unterschiedliche Schwachstellen brauchen unterschiedliche Maßnahmen; ein pauschaler „Alles aktualisieren“-Knopf ersetzt keine saubere Bestandsaufnahme.

Weiterlesen auf Luftpoet: PHP-Sicherheitslücken 2026 – Notfallupdate

Weitere Sicherheitsmeldung: Plex2Shell – Plex-Server absichern

Quellen und Faktenlage

Die Angaben zu CVE-2026-110264, CVSS-Wert, betroffenen Versionen und Patchständen stammen aus GitLabs Sicherheitsmitteilung vom 21. Oktober 2026. Die hier vollständig beschriebenen Update-Schritte orientieren sich an den Herstelleranleitungen; die Links darunter dienen ausschließlich als überprüfbare Quellen und zur Nachverfolgung künftiger Änderungen. Eine konkrete Kompromittierung wird nicht behauptet.

Herstellerwarnung: GitLab Critical Patch Release

Technische Upgrade-Planung: GitLab Upgrade Paths

Backup und Wiederherstellung: GitLab Restore Documentation

Neugierig auf mehr?

Du willst deinen Homeserver langfristig sicher betreiben? Auf Luftpoet findest du verständliche Anleitungen zu Linux, Proxmox, Docker und Self-Hosting – dazu aktuelle Sicherheitsmeldungen und praktische Erfahrungen aus meinen Technikprojekten.

Stöbere hier weiter: Zur Luftpoet-Startseite