GitLab-Lücken CVE-2026-110264 und CVE-2026-97229: Bin ich betroffen und was tun?

Was passiert ist

GitLab hat im Oktober 2026 zwei kritische Lücken im Regex-Compiler geschlossen, beide mit CVSS 10.0 (CVSS 3.1, AV:N/AC:L/PR:N):

• CVE-2026-97229 (Patch-Release vom 12. Oktober): „Integer Overflow issue in CI/CD Regular Expression Compiler“. Laut GitLab konnte ein nicht angemeldeter Angreifer unter bestimmten Bedingungen mit einem präparierten regulären Ausdruck in der CI/CD-Konfiguration beliebigen Code auf dem GitLab-Server ausführen.
• CVE-2026-110264 (Patch-Release vom 21. Oktober): „Integer Overflow issue in Regular Expression Compiler“. Wieder ein Integer Overflow beim Kompilieren eines präparierten regulären Ausdrucks, wieder Codeausführung ohne Login. Diesmal reicht der betroffene Bereich laut GitLab bis Version 7.0 zurück.

Wichtig: Wer nach dem ersten Release auf 19.4.2, 19.3.5 oder 19.2.8 aktualisiert hat, ist gegen CVE-2026-110264 noch nicht geschützt. Dafür braucht es die Versionen vom 21. Oktober.

Betroffen sind selbst betriebene Instanzen (CE und EE). GitLab.com läuft laut GitLab bereits mit den Fixes, GitLab-Dedicated-Instanzen wurden vor der Veröffentlichung gepatcht.

Betroffene und gefixte Versionen

Maßgeblich ist die zweite Lücke, CVE-2026-110264. Die Versionen vom 21. Oktober schließen beide Lücken.

CVE-2026-97229 betrifft laut GitLab nur die Zweige 19.2 (vor 19.2.8), 19.3 (vor 19.3.5) und 19.4 (vor 19.4.2).

Wird die Lücke ausgenutzt?

• Die beiden Release-Meldungen von GitLab sagen nichts über beobachtete Angriffe. GitLab hat aber für beide Lücken Erkennungsregeln für selbst betriebene Instanzen veröffentlicht, darunter „Onigmo native worker crash“.
• Im KEV-Katalog der CISA stehen beide CVEs nicht (Stand 25. Oktober 2026).

Kein KEV-Eintrag heißt nicht „kann warten“: CVSS 10.0, kein Login nötig und ein öffentlich erreichbarer Dienst sind genau die Kombination, die Angreifer zuerst ausprobieren. Wie du solche Lücken einordnest, erklärt der Artikel zu CVSS, EPSS und CISA KEV.

Bin ich betroffen? So prüfst du es

Auf dem GitLab-Server (Omnibus-Installation):

sudo gitlab-rake gitlab:env:info

Die Version steht unter „GitLab information“. Alternativ:

cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

Im Browser zeigt die Seite /help deiner Instanz die Version (nach dem Anmelden).

Bei Docker steht die Version im Image-Tag, zum Beispiel:

docker ps --format '{{.Image}}' | grep gitlab

gitlab/gitlab-ee:19.4.2-ee.0 ist betroffen, gitlab/gitlab-ee:19.4.3-ee.0 nicht. In Repos mit Infrastruktur-Code (Docker Compose, Helm, Ansible) steht der Tag meist direkt in der Konfiguration.

Fallstricke

Das erste Update reicht nicht. Wer am 12. Oktober schnell war und auf 19.4.2, 19.3.5 oder 19.2.8 gegangen ist, muss noch einmal ran.

Alte Zweige bekommen keinen Fix. Für Versionen vor 18.11 gibt es kein Patch-Release. Der Weg führt über ein Upgrade auf einen unterstützten Zweig, gegebenenfalls über mehrere Zwischenversionen (Upgrade-Pfad von GitLab beachten).

Downtime einplanen. Beide Releases enthalten Datenbank-Migrationen. Instanzen mit nur einem Knoten sind laut GitLab während des Updates nicht erreichbar, Installationen mit mehreren Knoten können ohne Downtime aktualisieren.

Gepinnte Images. latest oder ein Tag wie 19.4 zieht die neue Version erst beim nächsten Pull und Neustart. Ein fester Tag wie 19.4.2-ee.0 bleibt verwundbar, bis du ihn änderst.

Paket-Scanner sehen es nicht. Dependabot und andere SCA-Werkzeuge prüfen die Abhängigkeiten deiner Projekte, nicht die Version deines GitLab-Servers. Mehr dazu im Vergleich mit Dependabot.

Was du jetzt tust

1. Alle selbst betriebenen GitLab-Instanzen auflisten, auch Test- und Altinstanzen.
2. Auf 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 oder 18.11.13 aktualisieren, je nach Zweig.
3. Mit gitlab-rake gitlab:env:info oder /help auf der laufenden Instanz nachprüfen.
4. Die von GitLab veröffentlichten Erkennungsregeln anwenden und Logs auf Abstürze von Workern seit dem 12. Oktober sichten, wenn deine Instanz öffentlich erreichbar war.

Wenn du nicht sofort patchen kannst

GitLab nennt in beiden Meldungen keinen Workaround und empfiehlt das Update so schnell wie möglich. Bis dahin verringert sich das Risiko nur über allgemeine Maßnahmen:

• Die Instanz aus dem öffentlichen Internet nehmen und nur über VPN oder eine IP-Freigabeliste erreichbar machen. Beide Lücken lassen sich laut GitLab ohne Login ausnutzen, ein Angreifer muss die Instanz also nur erreichen können.
• Die Erkennungsregeln von GitLab aktivieren, um Angriffsversuche zu sehen.

Diese Maßnahmen ersetzen kein Update.

Ob weitere Komponenten in deinem Stack offene Lücken haben, zeigt der kostenlose Stack-Check.

Quellen

• GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13 (21. Oktober 2026)
• GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8 (12. Oktober 2026)
• CISA Known Exploited Vulnerabilities Catalog