Wer GitLab Self-Managed betreibt, hat die Lücke CVE-2026-97229 mit dem Update auf 19.4.2, 19.3.5 oder 19.2.8 geschlossen, denn GitLab hat das mitgelieferte Ruby gepatcht. Die Ursache steckt allerdings in Onigmo, der Regex-Engine von Ruby. Eigene Ruby-Anwendungen sind nur betroffen, wenn sie reguläre Ausdrücke aus fremden Eingaben kompilieren; dann brauchen sie Ruby 4.0.9, 3.4.12 oder 3.3.13. Die US-Behörde CISA führt die Schwachstelle seit dem 29. Oktober als aktiv ausgenutzt, ohne Angaben zu Angreifern oder Umfang. Vor dem Patchen sollten Sie deshalb Spuren sichern.
Was CISA am 29. Oktober in den Katalog aufgenommen hat
Am 29. Oktober 2026 hat die US-Behörde CISA zwei Einträge in ihren Katalog bekannter ausgenutzter Schwachstellen aufgenommen, kurz KEV. In ihrem Alert steht als Begründung „based on evidence of active exploitation“. Einer der Einträge ist CVE-2026-97229 für die GitLab Community Edition und die Enterprise Edition.
Die Schwachstelle gehört zur Klasse „Integer Overflow or Wraparound“ (CWE-190). Dabei läuft eine Zahl über ihren zulässigen Wertebereich hinaus und springt auf einen unerwarteten Wert, was in Speicherfehlern enden kann. Laut Katalogeintrag kann ein nicht authentifizierter Nutzer über einen speziell präparierten regulären Ausdruck in einer CI/CD-Konfiguration Code auf dem GitLab-Server ausführen. CI/CD steht für die automatisierten Build- und Auslieferungsabläufe, die GitLab aus Konfigurationsdateien steuert. Dass hierfür kein Konto nötig ist, erklärt die Höchstwertung von CVSS 10.0.
Was CISA nicht mitteilt, ist ebenso wichtig. Es gibt keine Angaben, wer die Lücke ausnutzt, gegen wen sich die Angriffe richten oder wie viele Instanzen betroffen sind. Beim Feld zur Verwendung in Ransomware-Kampagnen steht „Unknown“. „Aktiv ausgenutzt“ ist damit ein belegter Befund, aber kein Lagebild. Wer daraus ableitet, die eigene Instanz sei kompromittiert, überinterpretiert den Eintrag, wer ihn als theoretisch abtut, ignoriert ihn.
Die Frist im Eintrag nennt den 1. November 2026. Sie gilt für US-Bundesbehörden, die ihre Systeme bis dahin in Ordnung bringen müssen. Für Unternehmen in Deutschland oder der EU ist sie nicht verbindlich. Als Orientierung taugt sie trotzdem, denn sie zeigt, wie dringend die Behörde die Lage einstuft.
Auffällig ist das Feld „forensicTriage“, das bei dieser Lücke auf „Yes“ steht. Es signalisiert, dass nicht nur gepatcht, sondern vorab nach Hinweisen auf eine bereits erfolgte Kompromittierung gesucht werden soll. Wie das aussehen kann, zeigt ein anderer Fall mit forensischer Prüfung bei einem KEV-Eintrag, die Kernel-Lücke Fragnesia. Beim zweiten Eintrag desselben Tages, einer Denial-of-Service-Lücke in Cisco Secure Firewall ASA und FTD, die einen Neustart auslöst, steht „No“.
Der Katalogeintrag enthält außerdem einen Hinweis, der über GitLab hinausreicht: Andere Produkte könnten von demselben zugrunde liegenden Ruby/Onigmo-Integer-Overflow im Regex-Compiler betroffen sein. Welche, nennt CISA nicht.
Welche GitLab-Versionen die Lücke schließen
Die Reparatur steckt in einem kritischen Patch-Release, das GitLab am 12. Oktober 2026 veröffentlicht hat. Laut Release-Hinweis erschienen die Versionen 19.4.2, 19.3.5 und 19.2.8 für Community Edition (CE) und Enterprise Edition (EE).
Betroffen sind alle Installationen der Reihe 19.2 vor 19.2.8, der Reihe 19.3 vor 19.3.5 und der Reihe 19.4 vor 19.4.2. Welche Ausgabe Sie betreiben, spielt keine Rolle, CE und EE sind gleichermaßen erfasst. Die Zeile, die Sie in Ihrer Versionsanzeige suchen, ist also die Kombination aus Reihe und Patch-Stand.
Eine Besonderheit betrifft 19.3.4. Diese Version hatte laut GitLab einen Fehler, der Merge-Request-Seiten betraf, wenn die Ona-Integration aktiviert war. Behoben ist er in 19.3.5, die 19.3.4 ersetzt. Wer in der Reihe 19.3 bleibt, sollte deshalb direkt auf 19.3.5 gehen. Das Advisory 2026-016 von CERT-EU vom 12. Oktober nennt dagegen 19.3.4 als Fix-Version. Diese Angabe ist überholt, maßgeblich ist die Auskunft des Herstellers.
Die Schwachstelle trägt die Höchstwertung CVSS 10.0, im Vektor AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Das bedeutet in Klartext: Der Angriff läuft über das Netzwerk, ist einfach, braucht weder Rechte noch Zutun einer Person, reicht über die betroffene Komponente hinaus und wirkt sich auf Vertraulichkeit, Integrität und Verfügbarkeit maximal aus. Der Wert beschreibt die Schwere der Lücke, nicht die Zahl bekannter Angriffe. Belegt ist die Ausnutzung durch den KEV-Eintrag, nicht durch die Punktzahl.
GitLab empfiehlt nach eigener Aussage, dass alle Self-Managed-Installationen sofort auf eine dieser Versionen aktualisiert werden. GitLab.com läuft laut Hersteller bereits mit der gepatchten Version, und auch GitLab Dedicated ist gepatcht. Für diese beiden Betriebsformen ist nichts zu tun. Gemeint sind mit dem Aufruf also Teams, die GitLab selbst auf eigenen Servern oder in eigenen Containern betreiben.
Die Höchstwertung ist bei GitLab kein Einzelfall, auch eine frühere GitLab-Lücke mit CVSS 10 verlangte ein sofortiges Update. Das GitLab-Update bringt ein repariertes Ruby mit, aber es repariert nicht das Ruby, das Sie außerhalb von GitLab betreiben.
Warum Ruby-Anwendungen eigens dran sind
Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptClose-up of a developer's monitor with abstract blurred code lines and a highlighted warning symbol shape, dark room, cool screen glow, keyboard in foreground. Photorealistic editorial magazine photo, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks.GitLab ist in Ruby geschrieben und verarbeitet reguläre Ausdrücke, die Nutzende liefern, etwa Muster in der CI-Konfiguration. Genau dort greift die Lücke. Wie die Ruby-Projektmeldung vom 23. Oktober erklärt, betreffen mehrere Fehler Onigmo, die Regex-Engine von Ruby. GitLab habe herausgefunden, dass sie sich für Remote Code Execution auf GitLab-Servern nutzen lassen. Das Ruby-Team hat daraufhin Ruby 4.0.9, 3.4.12 und 3.3.13 veröffentlicht.
Die Meldung behandelt vier GitLab-CVEs zusammen. Für CVE-2026-97229, den Integer Overflow im Regex-Compiler, kam der Fix erstmals in 4.0.8, 3.4.12 und 3.3.13. Unter Ruby 4.0 ist CVE-2026-97229 also bereits ab 4.0.8 behoben; das Projekt verweist dennoch auf 4.0.9 als aktuellen Stand.
GitLab hat das mitgelieferte Ruby gepatcht. Für die Installation selbst genügt deshalb das GitLab-Update, ein separater Ruby-Tausch ist nicht nötig. Anders liegt der Fall bei Anwendungen, die Sie selbst entwickeln oder betreiben. Sie sind laut Ruby-Team nur dann betroffen, wenn sie reguläre Ausdrücke aus Strings kompilieren, die ein Angreifer kontrollieren kann. Wer dagegen feste, im Code hinterlegte Muster verwendet, erfüllt die Bedingung nicht.
Typische Konstellationen sind Software, die Nutzende eigene Filter, Suchmuster oder Validierungsregeln eintippen lässt und diese direkt als Regex übersetzt. Das ist eine Einordnung von dm, keine Aussage der Quelle: Prüfenswert ist jede Stelle, an der Text von außen in eine Regex-Kompilierung fließt. Ob Ihre Software dazugehört, lässt sich nur im eigenen Code beantworten.
Zwei naheliegende Schutzmaßnahmen helfen laut Ruby-Team nicht: Weder Regexp.timeout noch Längenbegrenzungen für Muster verhindern das Problem. Wer sich auf diese Mittel verlassen hat, ist also nicht abgesichert.
Wer nicht aktualisieren kann, sollte laut Ruby-Team keine nicht vertrauenswürdigen Muster kompilieren. Das ist die einzige genannte Übergangslösung. Bemerkenswert ist noch eine Formalie: Das Ruby-Projekt hat für diese Fehler keine eigenen CVEs beantragt. Wer seine Sicherheitsmeldungen nur nach Ruby-CVE-Nummern filtert, findet die Lücke dort deshalb nicht, sie taucht ausschließlich unter den GitLab-Kennungen auf.
Erst Spuren sichern, dann patchen
Der KEV-Eintrag trägt für CVE-2026-97229 die Markierung „forensicTriage: Yes“. Daraus ergibt sich die Reihenfolge: zuerst feststellen, ob eine Instanz schon betroffen war, dann das Update einspielen. Beim Patchen werden Dienste neu gestartet und Zustände überschrieben, was Spuren verwischen kann. Das ist eine Einordnung von dm, keine Anweisung der Behörde.
Hilfestellung liefert der Hersteller. GitLab hat zu dieser Lücke sechs Erkennungsregeln veröffentlicht, die Sie im Release-Hinweis finden. Sie gehören in die Hände derer, die Protokolle und Monitoring betreiben, und sollten dort in der aktuellen Fassung des Herstellers verwendet werden. Dass es sie gibt, ist selbst eine Information: Der Hersteller rechnet damit, dass Betreiber nach Anzeichen suchen.
Eine sinnvolle Abfolge lässt sich aus den Fakten ableiten, bleibt aber eine Einordnung von dm:
- Festhalten, welche GitLab-Version jede Self-Managed-Instanz derzeit hat und seit wann.
- Protokolle und Konfigurationen sichern, bevor das Update läuft.
- Die Erkennungsregeln des Herstellers gegen diese Daten anwenden.
- Dann auf 19.4.2, 19.3.5 oder 19.2.8 aktualisieren, je nach Reihe.
Für alles außerhalb der GitLab-Installation hilft eine Bestandsaufnahme. Auch hier gilt: Das ist eine dm-Einordnung. Wo laufen Runner, wo Container-Images, in denen ein eigenes Ruby steckt, und welche Version hat es? Ein Image, das vor Wochen gebaut wurde, trägt womöglich noch ein Ruby vor 4.0.9, 3.4.12 oder 3.3.13. Ein verbreiteter Denkfehler liegt hier nahe: Der Patch auf dem GitLab-Server wirkt nicht auf Images, die ihr eigenes Ruby mitbringen.
Dabei zählt nicht jede Ruby-Installation gleich. Entscheidend ist, ob die jeweilige Anwendung Muster aus fremden Eingaben kompiliert. Dort, wo das nicht der Fall ist, besteht nach Angabe des Ruby-Teams kein Handlungsdruck durch diese Lücke, wo es der Fall ist, gehört das Ruby-Update auf die Liste. Ein Ruby-Update ohne diese Prüfung ist nicht falsch, aber es beantwortet die Frage nicht, ob Sie betroffen waren.
Der Katalog deutet an, dass weitere Produkte vom gleichen Fehler berührt sein können, ohne sie zu benennen. Wer Software von Dritten einsetzt, die auf Ruby beruht, kann beim Hersteller nachfragen, welche Ruby-Version sie mitliefert. Eine Liste betroffener Produkte veröffentlicht CISA nicht, und das Fehlen einer Liste ist kein Beleg dafür, dass es keine weiteren gibt.
Noch einmal zur Frist: Der 1. November gilt für US-Bundesbehörden. Ob Ihre Instanz bis dahin oder erst eine Woche später aktualisiert wird, entscheidet sich an Ihrer eigenen Risikolage. Wegen der belegten Ausnutzung, der Höchstwertung und der Möglichkeit, dass Spuren bereits existieren, gehört die Sache dennoch an den Anfang der Aufgabenliste.
