GitLab: Kritische RCE-Lücke mit CVSS 10 betrifft zwölf Jahre Versionen

GitLab hat am 21. Oktober 2026 mehrere Sicherheitsupdates veröffentlicht. Eine der behobenen Schwachstellen sticht dabei deutlich heraus: CVE-2026-110264 erreicht mit CVSS 10,0 die höchstmögliche Bewertung.

Unter bestimmten Voraussetzungen könnte ein nicht angemeldeter Angreifer darüber eigenen Code auf einem selbst betriebenen GitLab-Server ausführen.

Besonders ungewöhnlich ist die Reichweite der Schwachstelle.

Betroffen sind laut GitLab nicht nur aktuelle Versionen, sondern praktisch sämtliche selbst verwalteten GitLab-Ausgaben zurück bis Version 7.0 aus dem Jahr 2014.

Wer einen eigenen GitLab-Server betreibt, sollte das Update deshalb nicht lange aufschieben.

CVE-2026-110264 ermöglicht möglicherweise Codeausführung ohne Login

Die Sicherheitslücke steckt in der Verarbeitung speziell präparierter regulärer Ausdrücke.

Dabei kann es während der Kompilierung eines solchen Ausdrucks zu einem Integer Overflow kommen.

Unter bestimmten, von GitLab bislang nicht näher erläuterten Bedingungen könnte ein Angreifer diesen Fehler ausnutzen, um beliebigen Code auf dem Server auszuführen.

Besonders kritisch:

Eine Anmeldung am GitLab-System ist dafür laut Sicherheitsmeldung nicht grundsätzlich erforderlich.

Genau diese Kombination aus möglicher Remote-Code-Ausführung und fehlender Authentifizierung erklärt die Bewertung von CVSS 10,0.

Betroffen sind selbstverwaltete GitLab-Installationen

Für Nutzer von GitLab.com besteht laut GitLab kein Handlungsbedarf.

Die Cloud-Plattform läuft bereits mit einer abgesicherten Version.

Auch GitLab-Dedicated-Umgebungen mit den entsprechenden internen Versionen sind bereits geschützt.

Relevant ist die Lücke deshalb vor allem für Self-Managed-GitLab-Installationen.

Also genau die Systeme, die Unternehmen oder Administratoren selbst auf eigenen Servern betreiben.

Und davon gibt es bekanntlich einige.

Selbst wer vor wenigen Tagen gepatcht hat, muss erneut ran

Ein Detail macht die Situation besonders unangenehm.

GitLab hatte erst am 12. Oktober Sicherheitsupdates für eine andere kritische Schwachstelle veröffentlicht.

Wer diese Updates brav installiert hat, könnte nun trotzdem wieder betroffen sein.

Die neuen sicheren Versionen liegen jeweils eine Patch-Version höher.

Das bedeutet:

Ein System, das vor wenigen Tagen vollständig aktuell war, kann heute schon wieder ein Sicherheitsupdate benötigen.

Security-Administratoren dürfte dieser Satz inzwischen bekannt vorkommen.

Diese GitLab-Versionen beheben die Lücke

GitLab hat die Schwachstelle ungewöhnlich breit zurückportiert.

Folgende Versionen enthalten laut Anbieter die Korrektur:

Wer eine der älteren Versionen einsetzt, sollte besonders genau hinschauen.

GitLab unterstützt normalerweise nur die aktuelle Hauptversion sowie die beiden vorherigen monatlichen Releases mit regulären Sicherheitsupdates.

Für diese Schwachstelle wurden jedoch zusätzliche ältere Versionen gepatcht.

GitLab geht bei CVSS 10 über die normale Update-Politik hinaus

Normalerweise wären zum jetzigen Zeitpunkt vor allem die Zweige 19.5, 19.4 und 19.3 im regulären Patchfenster.

Bei CVE-2026-110264 hat GitLab jedoch zusätzlich Korrekturen für:

• 19.2

• 19.1

• 19.0

• 18.11

bereitgestellt.

Das Unternehmen macht solche zusätzlichen Backports nach eigenen Angaben nur bei besonders schwerwiegenden Problemen.

Bei einer nicht authentifizierten möglichen Remote-Code-Ausführung mit CVSS 10,0 ist das durchaus nachvollziehbar.

Warum reicht die Schwachstelle bis ins Jahr 2014 zurück?

Der Grund liegt nicht unbedingt in einem modernen GitLab-Feature.

Betroffen ist vielmehr die Engine, mit der Ruby reguläre Ausdrücke verarbeitet.

Sie trägt den Namen Onigmo.

GitLab liefert diese Komponente innerhalb seiner eigenen Pakete aus und patcht sie im Rahmen eigener Builds.

Da Onigmo bereits seit vielen Jahren Bestandteil der GitLab-Pakete ist, reicht auch die verwundbare Codebasis entsprechend weit zurück.

Laut Bericht betrifft die Schwachstelle dadurch jede GitLab-Version ab 7.0.

Das ist ein Zeitraum von rund zwölf Jahren.

Bislang keine bestätigten Angriffe

Nach Angaben von GitLab gibt es bislang keine Hinweise darauf, dass CVE-2026-110264 bereits aktiv ausgenutzt wurde.

Auch eine Aufnahme in den Katalog der nachweislich ausgenutzten Schwachstellen der US-Sicherheitsbehörde CISA war zum im Bericht genannten Zeitpunkt nicht bekannt.

Das ist natürlich erfreulich.

Es bedeutet aber nicht, dass Administratoren gemütlich abwarten sollten.

Gerade bei einer Lücke mit CVSS 10,0 und der Möglichkeit einer nicht authentifizierten Codeausführung sollte man nicht darauf setzen, dass das so bleibt.

Kein Workaround vorhanden

Ein weiterer wichtiger Punkt:

GitLab nennt derzeit keine Übergangslösung, mit der sich die Schwachstelle zuverlässig entschärfen ließe.

Da außerdem nicht öffentlich erläutert wurde, welche konkreten Voraussetzungen ein Angriff erfüllen muss, können Administratoren auch nicht einfach anhand ihrer Konfiguration feststellen, ob sie praktisch betroffen sind.

Die sichere Lösung lautet daher:

Update installieren.

Das macht die Entscheidung zumindest übersichtlich.

GitLab veröffentlicht Erkennungsregeln für Angriffsversuche

Für Administratoren stellt GitLab zusätzlich zwei Detection-Regeln bereit.

Diese tragen die Bezeichnungen:

• Onigmo native worker crash

• Org mode render error burst

Die Regeln gehören zum offenen TLDR-Framework von GitLab und arbeiten mit GitLab-eigenen Anwendungsprotokollen.

Die Erkennungslogik wird im Sigma-Format bereitgestellt.

Damit können Administratoren ihre Logs nach Auffälligkeiten durchsuchen, die auf mögliche Ausnutzungsversuche hindeuten könnten.

Das ersetzt den Patch natürlich nicht.

Es kann aber helfen, im Nachhinein festzustellen, ob ungewöhnliche Aktivitäten stattgefunden haben.

Bereits die vierte Regex-RCE innerhalb eines Monats

Besonders auffällig ist, dass CVE-2026-110264 nicht allein dasteht.

Der Sicherheitsforscher mit dem Handle joaxcar hat innerhalb kurzer Zeit mehrere Schwachstellen rund um GitLabs Regex-Verarbeitung gemeldet.

Am 12. Oktober wurde beispielsweise CVE-2026-97229 geschlossen.

Auch diese Schwachstelle erreichte CVSS 10,0 und konnte unter bestimmten Umständen eine nicht authentifizierte Codeausführung ermöglichen.

Bereits am 23. September hatte GitLab mit:

• CVE-2026-93577

• CVE-2026-89078

zwei weitere Probleme im gleichen Umfeld beseitigt.

Diese beiden wurden mit CVSS 9,9 bewertet und setzten allerdings eine Anmeldung voraus.

Die aktuelle Lücke unterscheidet sich vor allem durch ihre enorme Versionsreichweite.

Insgesamt elf Sicherheitsprobleme behoben

Das GitLab-Update vom 21. Oktober behebt nicht nur CVE-2026-110264.

Insgesamt werden elf Sicherheitsprobleme geschlossen.

Neben der kritischen RCE-Lücke enthält das Update weitere Schwachstellen mit hoher, mittlerer und niedriger Einstufung.

Dazu gehören auch zwei interessante Probleme rund um Authentifizierung und Anmeldung.

Account-Übernahme bei spezieller SAML- und LDAP-Konfiguration

Die Schwachstelle CVE-2026-15723 wird mit CVSS 8,2 bewertet.

Unter bestimmten Voraussetzungen könnte ein bereits angemeldeter Nutzer damit möglicherweise die Kontrolle über ein anderes Benutzerkonto übernehmen.

Das Problem betrifft allerdings nur Umgebungen, in denen Administratoren gleichzeitig:

• SAML-Autolinking

• LDAP-Autolinking

aktiviert haben.

Damit ist die praktische Reichweite deutlich kleiner als bei der kritischen RCE-Lücke.

Trotzdem gehört auch dieser Fehler zu den Sicherheitsproblemen, die mit dem Update behoben werden.

Auch OAuth und OpenID Connect betroffen

Eine weitere Schwachstelle betrifft die Authentifizierungs-Endpunkte für OAuth und OpenID Connect.

CVE-2026-112212 erreicht CVSS 7,5.

Dabei handelt es sich um ein Cache-Poisoning-Problem.

In bestimmten Konfigurationen mit gemeinsam genutztem Cache könnte ein Angreifer Anmeldevorgänge auf einen von ihm kontrollierten Server umleiten.

Auch hier gilt:

Nicht jede GitLab-Installation ist automatisch betroffen.

Da das Security Release ohnehin installiert werden sollte, dürfte die kritische RCE-Lücke allerdings bereits genug Motivation für das Update liefern.

Bei GitLab 19.3 und 19.4 kann Downtime entstehen

Administratoren sollten beim Einspielen der Updates noch einen praktischen Punkt beachten.

Die Versionen:

19.4.3 und 19.3.6

bringen Datenbankänderungen mit.

Bei einer einzelnen GitLab-Instanz können diese während des Upgrades eine Unterbrechung verursachen.

Wer eine produktive Single-Node-Installation betreibt, sollte also besser ein entsprechendes Wartungsfenster einplanen.

Bei Multi-Node-Umgebungen bietet GitLab dagegen ein Zero-Downtime-Verfahren an.

Das Update sollte deswegen nicht verschoben werden.

Aber fünf Minuten Planung vor dem Upgrade schaden bekanntlich selten.

Was Administratoren jetzt tun sollten

Für Betreiber einer selbst verwalteten GitLab-Instanz würde ich die Lage relativ klar einordnen.

Zuerst die aktuell installierte Version prüfen.

Anschließend kontrollieren, welche der veröffentlichten Patch-Versionen für den eigenen Zweig vorgesehen ist.

Dann Backup beziehungsweise Wiederherstellungsmöglichkeit überprüfen und das Update einspielen.

Wer GitLab 19.3 oder 19.4 auf einem einzelnen Server betreibt, sollte die möglichen Datenbankänderungen und die dadurch entstehende Downtime einplanen.

Und wer entsprechende Logdaten besitzt, kann zusätzlich die von GitLab veröffentlichten Erkennungsregeln verwenden.

Mein Eindruck

Eine Sicherheitslücke mit CVSS 10,0 ist ohnehin nichts, was man besonders lange auf der To-do-Liste liegen lassen sollte.

Interessanter finde ich hier aber fast die Reichweite.

Wenn eine Schwachstelle praktisch jede GitLab-Version seit 2014 betrifft, wird deutlich, wie lange sich Fehler in tief eingebetteten Komponenten durch eine Softwarelandschaft ziehen können.

Dass GitLab sogar Versionen außerhalb des normalen Supportfensters mit Patches versorgt, zeigt ebenfalls, wie ernst das Unternehmen die Sache einschätzt.

Für Administratoren gibt es diesmal eigentlich wenig Interpretationsspielraum.

Wenn die GitLab-Instanz selbst betrieben wird und noch nicht auf einer der korrigierten Versionen läuft, sollte das Update zeitnah eingeplant werden.

Fazit

Mit CVE-2026-110264 schließt GitLab eine kritische Sicherheitslücke mit der maximalen Bewertung CVSS 10,0.

Unter bestimmten Bedingungen könnte ein nicht authentifizierter Angreifer über einen Integer Overflow in der Regex-Verarbeitung beliebigen Code auf einem selbst verwalteten GitLab-Server ausführen.

Betroffen sind GitLab-Versionen zurück bis Version 7.0 aus dem Jahr 2014.

GitLab hat deshalb Patches für ungewöhnlich viele Versionszweige veröffentlicht.

Ein Workaround steht nicht zur Verfügung und die genauen Voraussetzungen für einen erfolgreichen Angriff wurden bislang nicht öffentlich beschrieben.

Bislang gibt es nach Angaben des Herstellers keine Hinweise auf eine aktive Ausnutzung.

Für Betreiber selbst verwalteter GitLab-Instanzen sollte das trotzdem kein Grund sein zu warten.

Version prüfen, Wartungsfenster einplanen und den passenden Patch installieren.

Quellen

The Hacker News:
Critical GitLab Flaw (CVSS 10.0) Could Allow Unauthenticated RCE Across 12 Years of Releases
https://thehackernews.com/2026/10/critical-gitlab-flaw-cvss-100-could.html

GitLab – Security Patch Release 19.5.1:
https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/

GitLab – Detecting Security Incidents / TLDR:
https://docs.gitlab.com/security/detecting_security_incidents/