GitLab CVE-2026-97229: Der Fix steckt in Ruby, und eigene Builds bleiben offen

TL;DR — 90 Sekunden

• Was: Ein Integer-Overflow in der Größenberechnung des Regex-Compilers Onigmo in Ruby. GitLab erreicht ihn über reguläre Ausdrücke in .gitlab-ci.yml, und am Ende läuft ein Betriebssystembefehl als Benutzer git.
• Schwere: CVSS 10.0 laut GitLab (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). Seit dem 29. Oktober steht die Lücke im CISA-KEV-Katalog, Rapid7 hat einen PoC veröffentlicht, und EPSS liegt bei rund 27 Prozent.
• Wen es trifft: Self-Managed-Instanzen von CE und EE in den Linien 19.2 bis 19.4 vor dem Fix. Wer GitLab mit einem selbst installierten Ruby betreibt, bleibt auch nach dem GitLab-Update verwundbar, bis Ruby selbst aktualisiert ist.
• Was zu tun ist: Auf die aktuelle Patch-Version der eigenen Linie aktualisieren, mindestens 19.4.2, 19.3.5 oder 19.2.8. Bei eigenem Ruby zusätzlich auf Ruby 3.3.13, 3.4.12 oder 4.0.9 gehen, denn Ruby 3.2 bekommt keinen Fix mehr.
• Was vorher geschützt hätte: keine Selbstregistrierung und keine öffentlichen Projekte für Fremde, Ruby als eigene Komponente im Patch-Prozess und eine Egress-Sperre für den GitLab-Server. Ein Timeout für Regex-Auswertung hilft laut Ruby-Team nicht.

Ein Muster, das nach der Prüfung neu kompiliert wird

GitLab wertet in CI/CD-Konfigurationen reguläre Ausdrücke aus, etwa in Regeln, die Branches oder geänderte Pfade abgleichen. Diese Ausdrücke stammen von jedem, der eine .gitlab-ci.yml committen darf, und sind damit Eingaben von außen. GitLab prüft sie deshalb, bevor es sie benutzt. Laut Rapid7 besteht der präparierte Ausdruck diese Prüfung, solange er als kompaktes US-ASCII-Muster vorliegt.

Genau hier lag der Fehler. Trifft das Muster auf einen gültigen UTF-8-Pfad im Repository, kompiliert Onigmo, die Regex-Engine von Ruby, es für diese Kodierung neu, und zwar nach den Prüfungen von GitLab. Onigmo übersetzt ein Muster in ein Programm für eine eigene kleine virtuelle Maschine. Wiederholungen mit fester Untergrenze rollt der Compiler dabei aus, solange das Ergebnis eine Größengrenze nicht überschreitet. Laut Ruby-PR #19020 lief bei verschachtelten Wiederholungen schon das Produkt aus Länge und Untergrenze über, sodass die Prüfung gegen die Grenze fälschlich bestand. Aneinandergereihte Wiederholungen konnten das Programm außerdem über INT_MAX treiben, und dann liefen die relativen Sprungadressen im Programm über.

Warum das gefährlich wird, ergibt sich aus der Rolle dieser Sprungadressen. Zeigt ein Sprung im Regex-Programm an eine falsche Stelle, führt die Maschine Bytes als Instruktionen aus, die nie als solche gedacht waren. Rapid7 beschreibt, dass sich darüber vom Angreifer gesteuerte Onigmo-Operationen und schließlich ein Betriebssystembefehl als Benutzer git ausführen lassen. Den Fund hat Johan Carlsson über das HackerOne-Programm von GitLab gemeldet.

Die Lücke steht nicht allein. Laut Ruby-Ankündigung vom 23. Oktober gehen vier GitLab-CVEs auf drei Fehler in Onigmo zurück: einen Double-free nach einer Alternation (CVE-2026-89078), den hier beschriebenen Overflow der Programmgröße (CVE-2026-93577 und CVE-2026-97229) und einen Overflow interner IDs bei vielen Wiederholungen (CVE-2026-110264, den ich in einem eigenen Beitrag beschreibe). Betroffen ist laut Ruby-Team jede Anwendung, die Muster aus fremden Eingaben über Regexp.new, Regexp.union, Regexp.compile oder Interpolation in ein Literal kompiliert.

Was der Fix ändert

Der Fix in Ruby-PR #19020 setzt an zwei Stellen an. Der erste Commit vergleicht die Größe einer ausgerollten Wiederholung mit der Grenze über eine Division statt über eine Multiplikation, die überlaufen kann. Der zweite lehnt ein kompiliertes Programm ab, das für den Typ seiner Sprungadressen zu groß ist, und deckelt die Größe dazu beim Erzeugen der Instruktionen und nicht erst in der vorgelagerten Längenrechnung. Ein zu großes Muster endet damit in einem RegexpError statt in einem kaputten Programm.

Das verrät viel über die Ursache. Die Prüfung in GitLab war nicht falsch, sie sah nur ein anderes Programm als das, das später lief. Und Onigmo verließ sich darauf, dass eine Vorab-Rechnung stimmt, statt die Grenze dort durchzusetzen, wo das Programm tatsächlich entsteht. Bemerkenswert ist auch der zeitliche Ablauf: Der PR wurde laut GitHub am 25. September in den Hauptzweig von Ruby übernommen, das Ruby-Release mit allen Fixes erschien am 23. Oktober. GitLab hatte sein gebündeltes Ruby schon vorher selbst gepatcht. Wer Ruby aus einer anderen Quelle bezog, hatte in dieser Zeit keinen offiziellen Fix.

Voraussetzungen, betroffene Versionen und Exploit-Lage

Für den getesteten Weg braucht ein Angreifer laut Rapid7 Schreibzugriff auf einen Branch in einem öffentlichen Projekt, um dort eine präparierte .gitlab-ci.yml und einen passenden UTF-8-Pfad abzulegen. GitLab bewertet die Lücke trotzdem als ohne Anmeldung ausnutzbar, und auf vielen Instanzen trifft das praktisch zu. Wo sich jeder selbst registrieren und Projekte anlegen darf, ist ein solches Konto eine Formalität. Laut GitLab-Doku kann sich ab Werk jeder registrieren, der die Domain aufruft. Neue Instanzen verlangen dabei standardmäßig eine Freigabe durch Administratoren, ältere Instanzen haben diese Einstellung aber oft nicht, und wer Freigaben routiniert durchwinkt, hat sie praktisch auch nicht.

Die übrigen Zeilen stammen aus demselben Patch-Release vom 12. Oktober. Für CVE-2026-97229 nennt das Advisory nur die Linien 19.2 bis 19.4, sagt aber nicht, ob ältere Linien sicher sind. Die Auswahl erklärt sich aus der Wartungsrichtlinie von GitLab, nach der Sicherheitsfixes nur in die aktuelle und die beiden vorherigen Monatsversionen zurückportiert werden. Weil der Fehler in Onigmo liegt und ältere Linien kein gepatchtes Ruby mehr bekommen, würde ich Instanzen vor 19.2 als verwundbar behandeln. Ob der Angriffsweg dort genauso funktioniert, ist allerdings nicht belegt. GitLab.com läuft gepatcht, für GitLab Dedicated ist keine Aktion nötig.

Die Exploit-Lage hat sich seit Mitte Oktober deutlich verschärft. Rapid7 hat die Codeausführung auf einem offiziellen CE-Image der Version 19.4.1 nachgestellt und einen PoC veröffentlicht. Die CISA hat die Lücke am 29. Oktober wegen nachgewiesener aktiver Ausnutzung in den KEV-Katalog aufgenommen, US-Bundesbehörden sollen bis zum 1. November patchen. EPSS schätzt die Wahrscheinlichkeit einer Ausnutzung in den nächsten 30 Tagen am 30. Oktober auf rund 27 Prozent, das liegt im obersten Zwei-Prozent-Bereich aller bewerteten CVEs.

Der Angriff auf Alpine Linux und was er zeigt

Wie ein echter Angriff aussieht, hat Alpine Linux offen beschrieben. Die Instanz lief seit dem 13. Oktober auf 19.3.4, weil das Team versehentlich diese Version statt 19.3.5 eingespielt hatte. Am 20. Oktober begann ein frisch registriertes Konto, die Instanz abzutasten. Am 21. Oktober schickte der Angreifer präparierte CI-Konfigurationen, die achtmal GitLab-Worker zum Absturz brachten, und in vier dieser Fälle kam er laut Alpine ein Stück weit in die Kette, bevor sie am nächsten Schritt scheiterte. Nutzer sahen 502-Fehler und fehlgeschlagene CI-Jobs. Außerdem lud der Angreifer das GitLab-Container-Image von Alpine herunter, was das Team so deutet, dass er den Exploit auf genau diesen Build abstimmen wollte.

Der lehrreichste Teil folgte danach. Am 22. Oktober aktualisierte Alpine auf 19.3.6 und war trotzdem weiter verwundbar, wie das Team am 26. Oktober feststellte. Die Instanz nutzte ein normal installiertes Ruby und nicht das Ruby aus den offiziellen GitLab-Paketen, und GitLabs Fix ist ein Patch genau dieses gebündelten Ruby. Das Upstream-Ruby mit den Fixes erschien erst am 23. Oktober. Neue Versuche des Angreifers am 25. und 26. Oktober schlugen fehl, sein Konto war seit dem 23. gesperrt.

Alpine fand keinen Hinweis auf einen Erfolg, kann ihn aber nicht ausschließen. Ein gelungener Exploit hinterlässt laut Alpine weder einen Absturz noch eine Spur im Web-Log, einige Logs vom Angriffstag fehlen, und ausgehende Verbindungen wurden nicht protokolliert. Das Team hat GitLab deshalb von Grund auf neu aufgebaut, alle Passwörter zurückgesetzt und die geheimen Schlüssel von GitLab ersetzt. Releases, Images und Pakete aus dem fraglichen Zeitraum hat es gegen Aufzeichnungen außerhalb von GitLab geprüft und unverändert gefunden, Signaturschlüssel lagen nie auf dem Server.

Was ein erfolgreicher Angriff kostet, zeigt Alpines Liste der möglicherweise betroffenen Daten: Namen, E-Mail-Adressen und IPs der Nutzer, Passwort-Hashes, 2FA-Geheimnisse, CI/CD-Variablen und Runner-Tokens, Zugangsdaten für Webhooks und Mirrors, Hashes persönlicher Access Tokens sowie private Repositories und vertrauliche Issues. Eine GitLab-Instanz ist damit ein direkter Zugang zur Lieferkette aller Projekte, die dort gebaut werden.

Patch, Ruby und die Falle eigener Builds

Welcher Fix bei dir wirkt, hängt davon ab, woher dein Ruby kommt. Die Linux-Pakete von GitLab und die offiziellen Container-Images bringen ihr eigenes Ruby mit, das GitLab selbst gepatcht hat. Dort reicht das Update auf die aktuelle Patch-Version der eigenen Linie, mindestens 19.4.2, 19.3.5 oder 19.2.8. Am 21. Oktober folgten 19.5.1, 19.4.3, 19.3.6 und 19.2.9 mit weiteren Ruby-Patches und dem Fix für CVE-2026-110264. In der Linie 19.3 behebt 19.3.5 laut GitLab außerdem einen Fehler aus 19.3.4 bei aktivierter Ona-Integration.

Anders sieht es bei Installationen aus Quellen und bei eigenen Images aus, die Ruby aus der Distribution oder einem Basis-Image beziehen. Dort ändert das GitLab-Update nichts an Onigmo. Du brauchst zusätzlich Ruby 4.0.9, 3.4.12 oder 3.3.13, die laut Ruby-Team alle drei Fixes enthalten. Ruby 3.2 ist laut Wartungsplan seit April 2026 am Ende seiner Lebenszeit und taucht in der Ankündigung nicht auf. Alpine hat die Fixes für die Releases 3.21 bis 3.24 und edge über apk upgrade ausgeliefert und fordert Nutzer des eigenen Images auf, alpinelinux/gitlab:19.3.6 neu zu ziehen, weil vor dem 27. Oktober bezogene Images verwundbar sind.

Das Release enthält Datenbank-Migrationen. Instanzen mit einem Knoten haben laut GitLab Ausfallzeit, bis die Migrationen durchgelaufen sind, Instanzen mit mehreren Knoten können das Zero-Downtime-Verfahren nutzen.

Bis der Patch eingespielt ist, empfiehlt Rapid7, anonymen Zugriff auf öffentliche Projekte einzuschränken und unvertrauten Nutzern das Anlegen und Beschreiben öffentlicher Projekte zu verwehren. Das sperrt nur den gezeigten Angriffsweg und behebt den Compiler-Fehler nicht. Die passenden Schalter liegen laut GitLab-Doku unter Admin > Settings > General:

• New user account restrictions: Allow new user accounts abwählen oder Require admin approval for new user accounts aktivieren.
• Visibility and access controls: unter Restricted visibility levels die Stufe Public sperren. Dann können nur Administratoren öffentliche Projekte anlegen.
• Visibility and access controls: Default minimum role required to create projects anheben. Die Einstellung gilt laut Doku nur für neue Gruppen.

Härtung über den Patch hinaus

Zuerst eine Einordnung. Der Angriff braucht zwei Dinge: das Recht, eine CI-Konfiguration in ein Projekt zu bringen, und eine Regex-Engine, die ein fremdes Muster kompiliert. Ist er gelungen, läuft Code mit den Rechten von GitLab selbst und kommt an alles, was GitLab weiß. Wirksam ist deshalb, wer überhaupt Muster einschleusen darf, ob jede Komponente mit dem Fix wirklich gepatcht ist und wie viel ein kompromittierter Server preisgibt. Klassische Container-Härtung hilft hier wenig, weil der Angreifer im Prozess landet, der die Daten ohnehin besitzt.

Wer CI-Konfigurationen einbringen darf

Die gezeigte Kette beginnt mit einem Commit in ein öffentliches Projekt. Eine Instanz ohne Selbstregistrierung oder mit echter Freigabe neuer Konten und ohne öffentliche Projekte für Fremde nimmt Unbekannten diesen Einstieg. Bei Alpine kam der Angriff genau über ein frisch registriertes Konto. Für Open-Source-Projekte, die Beiträge von außen annehmen müssen, ist das schwer umzusetzen. Dort lohnt es, Forks und Merge Requests von außen klar von Projekten zu trennen, in denen CI mit Zugang zu Geheimnissen läuft. Diese Maßnahme verkleinert die Zahl der Angreifer, sie hilft aber nicht gegen ein kompromittiertes internes Konto.

Ruby als eigene Komponente im Patch-Prozess

Alpines Fall zeigt, dass der Fix in einer Abhängigkeit stecken kann und das Update der Anwendung dann nichts bewirkt. Wer GitLab aus Quellen oder auf einem eigenen Basis-Image betreibt, muss Ruby deshalb mit derselben Dringlichkeit verfolgen wie GitLab selbst und die Release Notes jedes Security-Release auf Komponenten-Patches lesen. Das empfiehlt Alpine inzwischen auch für sich. Ein CVE-Scanner genügt dafür allein nicht. Laut Glitchwire hat das Ruby-Team für diese Fehler keine eigenen CVEs beantragt, die vier Nummern hat GitLab vergeben. Ein Scanner, der das Ruby-Paket prüft, findet dann womöglich keine passende Meldung, und einer, der nur die GitLab-Version vergleicht, meldet nach dem Update grünes Licht. Diese Lücke im Scan leite ich aus der Vergabe der Nummern ab. Am sichersten ist es, die offiziellen Pakete oder Images zu nutzen, wenn es keinen zwingenden Grund für einen eigenen Build gibt.

Weniger Geheimnisse auf dem GitLab-Server

Wie teuer ein Einbruch wird, entscheidet, was der Server speichert. CI/CD-Variablen mit langlebigen Cloud-Schlüsseln sind nach einer Kompromittierung verloren. GitLab kann Jobs über das Schlüsselwort id_tokens kurzlebige OIDC-Tokens ausstellen, mit denen sich ein Job bei AWS, Vault oder anderen Anbietern anmeldet, ohne dass ein dauerhaftes Geheimnis in GitLab liegt. Signaturschlüssel für Releases gehören ebenfalls nicht auf den Server. Bei Alpine lagen sie nie dort, und deshalb ließ sich die Unversehrtheit der Releases gegen Aufzeichnungen außerhalb von GitLab prüfen. Signierte Release-Tags, die Alpine als Lehre einführen will, machen genau diese Prüfung unabhängig von GitLab.

Egress-Sperre und Protokollierung für den Server

Nach einer Codeausführung will ein Angreifer in der Regel Daten herausholen oder eine Verbindung nach außen öffnen. Eine Egress-Regel, die dem GitLab-Server nur die Ziele erlaubt, die er für Mirrors, Webhooks, Mail und Updates wirklich braucht, erschwert beides. In Kubernetes geht das über NetworkPolicies mit policyTypes: [Egress], auf einer VM über Firewall-Regeln oder Security Groups. Mindestens solltest du ausgehende Verbindungen protokollieren und Logs länger als 14 Tage aufbewahren. Genau diese Lücke hat Alpine daran gehindert, einen Erfolg des Angreifers sicher auszuschließen. Die Regel hat Pflegeaufwand, weil jede neue Integration eine Freigabe braucht, und Webhooks zu beliebigen Zielen widersprechen ihr grundsätzlich.

Was hier nicht hilft

Ein Timeout für Regex-Auswertung wie Regexp.timeout schützt laut Ruby-Team nicht vor diesen Fehlern, und eine Längengrenze für Muster hilft ebenfalls nicht zuverlässig, weil sich einige Fehler mit kurzen Mustern auslösen lassen. Eine Web Application Firewall sieht das Muster nicht als Angriff, denn es kommt als Teil eines Git-Pushs in einer YAML-Datei und nicht in einer HTTP-Anfrage an die Weboberfläche. Das leite ich aus dem Angriffsweg ab. runAsNonRoot, entzogene Capabilities, seccomp und ein schreibgeschütztes Dateisystem bleiben für GitLab-Pods sinnvoll, weil sie einen Ausbruch auf den Knoten erschweren. Sie schützen aber nicht die Daten, an die der Angreifer schon als Benutzer git kommt.

Mehr zu Egress-Regeln, Geheimnissen und Update-Abläufen findest du in der Serie TYPO3 auf Kubernetes unter IT-Grundschutz.

Erkennung und Prüfung

Ob du betroffen bist, klärst du in zwei Schritten. Die laufende GitLab-Version zeigt laut Doku Help > Help in der linken Seitenleiste. Liegt sie in den Linien 19.2 bis 19.4 unter dem Fix, ist die Instanz verwundbar. Danach kommt die Frage, die Alpine übersehen hatte: Welches Ruby läuft tatsächlich? Bei den offiziellen Paketen und Images ist es das gebündelte Ruby von GitLab. Bei Installationen aus Quellen und eigenen Images prüfst du die Ruby-Version im Container oder auf dem Host und vergleichst sie mit 3.3.13, 3.4.12 und 4.0.9. Zur Angriffsfläche gehört außerdem, ob sich Fremde selbst registrieren können und ob es öffentliche Projekte gibt, in die sie schreiben dürfen.

Einen Angriffsversuch erkennst du nur an seinen Begleiterscheinungen. GitLab und Rapid7 haben keine IoCs veröffentlicht. Bei Alpine fielen fehlgeschlagene Versuche als abgestürzte GitLab-Worker auf, Nutzer sahen 502-Fehler und fehlgeschlagene CI-Jobs. Voraus gingen ein neu registriertes Konto, das die Instanz abtastete, und der Download des GitLab-Images. Aus diesem Ablauf leite ich ab, worauf du achten solltest: neue Konten mit Pushs von .gitlab-ci.yml in öffentliche Projekte, Häufungen von Worker-Abstürzen und Pfade mit ungewöhnlichen UTF-8-Zeichen in frischen Commits. Ein gelungener Angriff hinterlässt laut Alpine allerdings keinen Absturz und keine Spur im Web-Log. Ohne protokollierte ausgehende Verbindungen bleibt dann wenig, woran du ihn erkennst.

Bei einem Verdacht empfiehlt sich Alpines Vorgehen. Sperre das verdächtige Konto, nimm die Instanz vom Netz und baue sie aus einem gepatchten Stand neu auf, statt im laufenden System aufzuräumen. Danach setzt du Passwörter zurück, ersetzt die geheimen Schlüssel von GitLab und rotierst Runner-Tokens, CI/CD-Variablen, Access Tokens sowie Zugangsdaten für Webhooks und Mirrors. Prüfe anschließend Releases und Artefakte gegen Aufzeichnungen außerhalb von GitLab.

Betreiberempfehlung

Akut handeln solltest du, wenn deine Self-Managed-Instanz in den Linien 19.2 bis 19.4 vor dem Fix läuft oder ein eigenes Ruby vor 3.3.13, 3.4.12 beziehungsweise 4.0.9 nutzt und aus dem Internet erreichbar ist. Die Ausnutzung ist bestätigt, ein PoC ist öffentlich, und offene Registrierung oder öffentliche Projekte machen die Instanz zum leichten Ziel. Patche außerhalb des regulären Wartungsfensters, prüfe danach die tatsächliche Ruby-Version und plane bei einem Knoten die Ausfallzeit für die Migrationen ein.

Beobachten genügt, wenn du GitLab.com oder GitLab Dedicated nutzt. Für Self-Managed reicht das reguläre Fenster nur, wenn die Instanz nicht öffentlich erreichbar ist, keine Selbstregistrierung erlaubt und keine öffentlichen Projekte führt. Das Update bleibt wegen der weiteren High-Lücken im selben Release trotzdem Pflicht.

Wie bei jeder Lücke gilt auch hier: Patches und Updates gehören automatisiert. Wenn Renovate oder Dependabot neue GitLab-Images, Helm-Charts und Basis-Images samt Ruby als Merge Request vorschlagen und die Pipeline sie gegen eine Staging-Instanz testet, ist ein kritisches Security-Release eine Sache von Stunden statt Wochen. Alpines Fall zeigt den Wert dieser Disziplin besonders deutlich, denn dort führten eine von Hand gewählte falsche Patch-Version und ein vergessenes Ruby zu einer Woche Verwundbarkeit. Eine Karenzzeit für Routine-Updates schützt vor kompromittierten Releases, Sicherheitsupdates nimmst du davon aus. Scheitern Migrationen oder Integrationen, fällt das in Staging auf und nicht auf der produktiven Instanz. Wer von Hand aktualisiert, hat in der Urlaubszeit schnell Wochen ohne Patch und danach ein Sammel-Update über mehrere Versionen mit entsprechend vielen Migrationen.

Fazit

CVE-2026-97229 zeigt zwei Dinge, die weit über GitLab hinausreichen. Das erste betrifft die Prüfung von Eingaben: GitLab hat das Muster geprüft, aber nicht das Programm, das Onigmo später daraus baute, und wer fremde Muster kompilieren lässt, hängt an der Robustheit der Engine. Das zweite betrifft den Patch-Prozess. Der Fix lag in Ruby, das Update der Anwendung war bei eigenem Ruby wirkungslos, und für Alpine hat genau dieser Unterschied eine Woche Verwundbarkeit und einen kompletten Neuaufbau bedeutet. Wer eine Anwendung selbst baut, übernimmt die Verantwortung für jede Komponente, die der Hersteller sonst mitliefert. Es lohnt sich, die eigenen Builds daraufhin durchzugehen, wo Laufzeit, Bibliotheken oder Basis-Images von dem abweichen, was der Hersteller testet und patcht.

Quellen

• GitLab: Critical Patch Release 19.4.2, 19.3.5, 19.2.8 (12. Oktober 2026)
• GitLab: Patch Release 19.5.1, 19.4.3, 19.3.6, 19.2.9 (21. Oktober 2026)
• Ruby: Regexp fixes for GitLab CVEs (23. Oktober 2026)
• Ruby PR #19020: Avoid overflow in the regexp compiler's program size arithmetic
• Ruby: Wartungsstatus der Branches
• Alpine Linux: GitLab security incident, attempted exploitation of CVE-2026-97229
• Rapid7: CVE-2026-97229, Critical Unauthenticated Remote Code Execution in GitLab
• The Hacker News: CISA Adds Actively Exploited GitLab RCE to KEV
• CISA: Known Exploited Vulnerabilities Catalog
• Glitchwire: Ruby patches Onigmo regex bugs
• FIRST EPSS: CVE-2026-97229
• GitLab Docs: Sign-up restrictions
• GitLab Docs: Visibility and access controls
• GitLab Docs: OpenID Connect (OIDC) Authentication Using ID Tokens
• GitLab Docs: Find the GitLab version
• GitLab Docs: Maintenance policy