Wer GitLab selbst betreibt, sollte dringend seine Version prüfen. Nach Zählung der Shadowserver Foundation waren am 1. November mehr als 11.300 öffentlich erreichbare GitLab-Instanzen für die kritische Lücke CVE-2026-110264 anfällig. Bei rund 39.000 GitLab-Instanzen, die die gemeinnützige Organisation täglich im Netz sieht, sind das fast drei von zehn. Eine eng verwandte Schwachstelle, CVE-2026-97229, wird bereits für Angriffe ausgenutzt: Die US-Cybersicherheitsbehörde CISA führt sie seit dem 29. Oktober in ihrem Katalog aktiv ausgenutzter Lücken (Known Exploited Vulnerabilities, KEV). Für sie zählte Shadowserver noch mehr als 1000 ungepatchte Server. Beide Lücken erlauben laut GitLab Angreifern ohne Anmeldung, beliebigen Code auf dem Server auszuführen, beide tragen den Höchstwert CVSS 10,0.

Zwei Integer-Überläufe in Rubys Regex-Engine

Die Ursache liegt nicht im GitLab-Code selbst, sondern in Onigmo, der Regex-Engine der Programmiersprache Ruby. GitLab erzeugt an mehreren Stellen reguläre Ausdrücke aus Mustern, die Nutzer liefern, etwa aus CI/CD-Konfigurationen. Präparierte Muster können beim Kompilieren den Speicher beschädigen, was nach Angaben des Ruby-Projekts bis zur Codeausführung auf GitLab-Servern führen kann.

CVE-2026-97229 steckt im CI/CD Regular Expression Compiler: Ein speziell gestalteter regulärer Ausdruck in einer CI/CD-Konfiguration löst einen Integer-Überlauf aus. Betroffen sind GitLab Community und Enterprise Edition (CE/EE) ab 19.2 vor 19.2.8, ab 19.3 vor 19.3.5 und ab 19.4 vor 19.4.2. GitLab schloss die Lücke am 12. Oktober. CVE-2026-110264 ist ein weiterer Überlauf beim Kompilieren regulärer Ausdrücke und reicht bis GitLab 7.0 zurück. Laut den Erkennungsregeln, die GitLab dazu veröffentlicht hat, führt der Angriffsweg hier über die Darstellung von Org-mode-Dateien (.org); nötig sei lediglich ein öffentliches Projekt, das die präparierte Datei enthält. Die Korrekturen erschienen am 21. Oktober in den Versionen 19.5.1, 19.4.3 und 19.3.6 sowie als Backports in 19.2.9, 19.1.9, 19.0.10 und 18.11.13. Gemeldet hat beide Fehler der Sicherheitsforscher Johan Carlsson (joaxcar) über GitLabs Bug-Bounty-Programm.

Wichtig für alle, die nur das Update vom 12. Oktober eingespielt haben: Die Versionen 19.4.2, 19.3.5 und 19.2.8 schließen zwar CVE-2026-97229, nicht aber CVE-2026-110264. Für CVE-2026-110264 gibt es bislang keinen KEV-Eintrag; eine bestätigte Ausnutzung war laut Techzine bis Anfang November nicht bekannt.

Bei eigener Ruby-Laufzeit reicht das GitLab-Update nicht

Weil die Korrektur ein Patch für Ruby ist, steckt sie laut GitLab nur in den offiziellen Linux-Paketen und Container-Images. Wer GitLab aus dem Quellcode installiert hat oder ein eigenes Container-Image mit eigener Ruby-Laufzeit nutzt, muss zusätzlich auf Ruby 3.3.13, 3.4.12 oder 4.0.9 (oder neuer) aktualisieren. Das Ruby-Projekt veröffentlichte diese Versionen am 23. Oktober. Es betont, dass grundsätzlich jede Ruby-Anwendung gefährdet ist, die reguläre Ausdrücke aus nicht vertrauenswürdigen Zeichenketten erzeugt, und dass Regexp.timeout nicht davor schützt. Auch CISA weist im KEV-Eintrag darauf hin, dass andere Produkte von demselben Onigmo-Fehler betroffen sein können.

Wie real diese Falle ist, zeigt Alpine Linux. Bei der GitLab-Instanz des Projekts versuchte ein Angreifer am 20. und 21. Oktober, CVE-2026-97229 auszunutzen, und zwar über ein frisch registriertes Konto und präparierte CI-Konfigurationen. GitLab-Worker-Prozesse stürzten dabei acht Mal ab. Alpine hatte am 13. Oktober versehentlich auf 19.3.4 statt auf die korrigierte 19.3.5 aktualisiert. Das spätere Update auf 19.3.6 schloss die Lücke nicht, weil das Alpine-Image die Ruby-Version der Distribution verwendet. Hinweise auf einen erfolgreichen Einbruch fand das Team nicht, ausschließen konnte es ihn aber auch nicht: Ein erfolgreicher Exploit hinterlasse weder einen Absturz noch Spuren in den Web-Logs, und ein Teil der Protokolle vom Angriffstag fehlte. Alpine setzte die Instanz deshalb komplett neu auf, setzte alle Passwörter zurück und tauschte die geheimen Schlüssel von GitLab aus. Seit dem 29. Oktober läuft sie mit GitLab 19.3.7 und Ruby 3.3.13.

So prüfst du deine GitLab-Version und aktualisierst

GitLab.com und GitLab Dedicated sind laut Hersteller bereits abgesichert. Selbst betriebene Instanzen sollten auf den neuesten Patch-Stand ihres Release-Zweigs gebracht werden. Das sind (Stand 5. November) die Versionen vom 29. Oktober: 19.5.3, 19.4.5, 19.3.7, 19.2.10, 19.1.10, 19.0.11 und 18.11.14. Sie enthalten beide Regex-Korrekturen und entziehen zusätzlich acht kompromittierten Zwischenzertifikaten von eMudhra das Vertrauen. Mindestens nötig sind 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 oder 18.11.13. Die installierte Version zeigt die Hilfeseite /help im Webinterface oder die Kommandozeile:

# Omnibus-Paketinstallation
sudo gitlab-rake gitlab:env:info | grep -A2 "GitLab information"
cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

# Docker (Containername anpassen)
docker exec gitlab cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

# Quellcode-Installation: zusätzlich die Ruby-Version prüfen
ruby -v

Das Update innerhalb des eigenen Zweigs ist schnell erledigt. Wer über mehrere Minor-Versionen springt, muss die von GitLab vorgegebenen Upgrade-Pfade einhalten. Beispiele für Debian/Ubuntu und Docker mit der Enterprise Edition (für CE gitlab-ce und -ce.0 verwenden):

# Debian/Ubuntu (Version des eigenen Zweigs einsetzen)
sudo apt update
sudo apt install gitlab-ee=19.5.3-ee.0

# Docker: Image-Tag in der Compose-Datei anpassen, dann
docker pull gitlab/gitlab-ee:19.5.3-ee.0
docker compose up -d
Screenshot der Pipeline-Übersicht in GitLab mit mehreren erfolgreich durchlaufenen CI/CD-Pipelines und der Schaltfläche CI lint

Über CI/CD-Konfigurationen gelangt der präparierte reguläre Ausdruck von CVE-2026-97229 auf den Server. Screenshot: Addshore, Lizenz CC0, via Wikimedia Commons

Spuren eines Angriffs finden

GitLab hat für beide Lücken Erkennungsregeln in seinem offenen Projekt TLDR veröffentlicht. Typische Hinweise sind demnach HTTP-Fehler 502 im Workhorse-Log bei POST-Anfragen an den CI-Lint-Endpunkt /api/v4/projects/:id/ci/lint oder an /api/graphql, Absturzberichte mit [BUG] im Puma-Log, deren Backtrace Onigmo-Funktionen wie onig_compile oder das Gem org-ruby nennt, sowie gehäufte Timeout::Error-Meldungen des Renderers OtherMarkup bei .org-Dateien im Exceptions-Log. Für Omnibus-Installationen lassen sich die Logs so durchsuchen (bei Helm oder Quellcode-Installation weichen die Pfade ab):

# 502 auf CI-Lint- oder GraphQL-Endpunkt (CVE-2026-97229)
grep -E '"uri":"[^"]*(ci/lint|/api/graphql)' /var/log/gitlab/gitlab-workhorse/current* | grep '"status":502'

# Native Abstürze mit Onigmo- oder org-ruby-Bezug
grep -B1 -A20 '\[BUG\]' /var/log/gitlab/puma/puma_stderr.log* | grep -E 'org-ruby|onig_compile|compile_tree|match_at'

# Render-Timeouts bei .org-Dateien je Client (CVE-2026-110264)
grep '"exception.class":"Timeout::Error"' /var/log/gitlab/gitlab-rails/exceptions_json.log* \
  | grep '"extra.class_name":"OtherMarkup"' | grep -o '"meta.client_id":"[^"]*"' | sort | uniq -c | sort -rn

Keine Treffer sind allerdings keine Entwarnung. GitLab weist ausdrücklich darauf hin, dass ein erfolgreicher Exploit von CVE-2026-110264 leise verläuft und nicht zuverlässig zum Absturz führt. Ein Angreifer mit Codeausführung könnte laut GitLab die Instanz-Geheimnisse aus gitlab-secrets.json, alle CI/CD-Variablen sowie Runner- und Zugriffstoken abgreifen. Wer Treffer findet oder seine Instanz lange ungepatcht im Netz hatte, sollte sie deshalb wie Alpine als kompromittiert behandeln: Passwörter, Zugriffstoken, Runner-Token, Deploy-Keys, CI/CD-Variablen sowie Webhook- und Integrationsgeheimnisse erneuern. Alpine rät außerdem, ausgehende Verbindungen des GitLab-Hosts mitzuschreiben, Logs länger als 14 Tage aufzubewahren und kritische GitLab-Sicherheitsupdates innerhalb eines Tages einzuspielen.

Quellen

Bildnachweis