Die US-Cybersicherheitsbehörde CISA hat CVE-2026-97229 am 29. Oktober 2026 in ihren Katalog aktiv ausgenutzter Schwachstellen (KEV) aufgenommen. Die Lücke in GitLab Community Edition und Enterprise Edition erreicht den Höchstwert CVSS 10.0: Über einen präparierten regulären Ausdruck in einer CI/CD-Konfiguration kann ein nicht angemeldeter Angreifer Code auf dem GitLab-Server ausführen. GitLab hat die Patches bereits am 12. Oktober veröffentlicht. Der Fall der Alpine-Linux-Infrastruktur zeigt allerdings, dass ein GitLab-Update allein nicht in jedem Setup ausreicht.
Wer GitLab selbst betreibt, sollte deshalb nicht nur die Versionsnummer prüfen, sondern auch, welche Ruby-Version die eigene Installation tatsächlich nutzt. Wir fassen zusammen, was bekannt ist, wer betroffen ist und was Admins jetzt tun sollten.
Key Takeaways
- CVE-2026-97229 ist ein Integer Overflow im Regex-Compiler für CI/CD-Konfigurationen, bewertet mit CVSS 10.0. Ohne Anmeldung ist Remote Code Execution möglich.
- Betroffen sind GitLab CE/EE 19.2 vor 19.2.8, 19.3 vor 19.3.5 und 19.4 vor 19.4.2. GitLab.com und GitLab Dedicated sind laut GitLab bereits gepatcht.
- CISA führt die Lücke seit dem 29. Oktober als aktiv ausgenutzt. US-Bundesbehörden müssen bis zum 1. November handeln, eine forensische Prüfung ist vorgeschrieben.
- Der eigentliche Fehler steckt in Onigmo, der Regex-Engine von Ruby. Wer GitLab mit eigener Ruby-Version betreibt, braucht zusätzlich Ruby 3.3.13, 3.4.12 oder 4.0.9.
- Alpine Linux meldet einen Angriffsversuch am 20. und 21. Oktober, hat keinen Beleg für einen Erfolg gefunden, die Instanz aber vorsorglich komplett neu aufgebaut.
Was ist CVE-2026-97229?
Laut dem GitLab Critical Patch Release 19.4.2, 19.3.5 und 19.2.8 handelt es sich um einen „Integer Overflow issue in CI/CD Regular Expression Compiler“. GitLab beschreibt die Folgen so: Unter bestimmten Bedingungen konnte ein nicht authentifizierter Nutzer über einen speziell präparierten regulären Ausdruck in einer CI/CD-Konfiguration beliebigen Code auf dem GitLab-Server ausführen, weil reguläre Ausdrücke nicht ausreichend validiert wurden. Der CVSS-Vektor lautet AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, also Angriff über das Netz, geringe Komplexität, keine Rechte und keine Nutzerinteraktion nötig.
Gemeldet hat die Lücke der Sicherheitsforscher Johan Carlsson (joaxcar) über das Bug-Bounty-Programm von GitLab bei HackerOne. Der Patch-Release vom 12. Oktober enthält insgesamt 24 Sicherheitskorrekturen, CVE-2026-97229 ist die einzige mit der Einstufung „Critical“. Zusätzlich hat GitLab sechs Erkennungsregeln für selbst betriebene Instanzen veröffentlicht, darunter Abstürze des nativen Onigmo-Workers, abgelehnte CI-Regex-Prüfungen und Fehlerhäufungen beim CI-Lint-Endpunkt.
Der Kern des Problems liegt in Ruby
GitLab kompiliert reguläre Ausdrücke, die Nutzer etwa in CI-Konfigurationen angeben, mit Regexp.new. Wie das Ruby-Team in seinem Hinweis vom 23. Oktober erklärt, konnten speziell gebaute Muster beim Kompilieren Speicher beschädigen. Daraus ließ sich auf GitLab-Servern Remote Code Execution machen. CVE-2026-97229 geht auf einen Integer Overflow bei der Größe eines kompilierten Musters zurück.
Insgesamt hängen vier GitLab-CVEs an Fehlern in Onigmo: CVE-2026-89078 (Double Free im Parser, behoben in GitLab 19.4.1), CVE-2026-93577 (Integer Overflow, 19.4.1), CVE-2026-97229 (19.4.2) und CVE-2026-110264 (Überlauf interner IDs bei vielen Wiederholungen, 19.5.1). GitLab hat die Fehler in seinen offiziellen Paketen und Container-Images behoben, indem es die mitgelieferte Ruby-Version patcht. Upstream liefert Ruby die Korrekturen seit dem 23. Oktober in den Versionen 4.0.9, 3.4.12 und 3.3.13 aus.
Wichtig für alle Ruby-Entwickler: Laut Ruby-Team sind nur Anwendungen betroffen, die reguläre Ausdrücke aus Zeichenketten kompilieren, die ein Angreifer kontrolliert, etwa über Regexp.new, Regexp.union, Regexp.compile oder per Interpolation wie /#{input}/. Wer nur selbst geschriebene Muster nutzt, ist nicht betroffen. Regexp.timeout schützt ausdrücklich nicht, und auch eine Längenbegrenzung hilft nicht zuverlässig, weil manche Fehler schon mit kurzen Mustern ausgelöst werden können. Eigene CVE-Nummern für Ruby hat das Ruby-Team bislang nicht beantragt. Es verweist für Scanner auf die GitLab-CVEs.
Warum CISA jetzt Alarm schlägt
CISA hat CVE-2026-97229 am 29. Oktober gemeinsam mit einer Cisco-Lücke (CVE-2026-76418) in den KEV-Katalog aufgenommen, „based on evidence of active exploitation“. Für Bundesbehörden gilt nach der Richtlinie BOD 26-04 eine Frist bis zum 1. November 2026. Außerdem verlangt CISA eine forensische Prüfung, also den Nachweis, ob ein System bereits vor dem Patch kompromittiert wurde. Ob die Lücke in Ransomware-Kampagnen genutzt wird, ist laut Katalog unbekannt. Bemerkenswert ist ein Hinweis in den Katalognotizen: Auch andere Produkte könnten über dasselbe Ruby/Onigmo-Problem betroffen sein.
Der Fall Alpine Linux: Update eingespielt, Lücke trotzdem offen
Wie real die Gefahr ist, zeigt ein ausführlicher Vorfallbericht von Alpine Linux vom 28. Oktober. Am 20. und 21. Oktober schickte ein frisch registriertes Konto präparierte CI-Konfigurationen an die GitLab-Instanz des Projekts. Die lief noch auf 19.3.4, weil das Team am 13. Oktober versehentlich auf 19.3.4 statt auf die gefixte 19.3.5 aktualisiert hatte. Die Angriffe brachten GitLab-Worker achtmal zum Absturz, in vier Fällen kam der Angreifer laut Alpine ein Stück weit durch den Exploit und scheiterte am nächsten Schritt. Er lud außerdem das GitLab-Container-Image des Projekts herunter, was Alpine als Hinweis wertet, dass der Exploit auf den exakten Build abgestimmt werden sollte.
Das Upgrade auf GitLab 19.3.6 am 22. Oktober schloss die Lücke nicht. Alpine nutzte im eigenen Image Standard-Ruby, die Korrektur steckt aber nur im gepatchten Ruby der offiziellen GitLab-Pakete. Erst am 26. Oktober fiel auf, dass die Instanz weiter verwundbar war. Alpine fand keinen Beleg für ausgeführten Code, kann einen Erfolg aber nicht ausschließen, weil ein erfolgreicher Exploit weder Absturz noch Spuren in den Weblogs hinterlassen würde und Teile der Logs fehlen. Das Projekt hat die Instanz deshalb neu aufgebaut, alle Passwörter zurückgesetzt und die Secret Keys von GitLab ersetzt. Pakete, Signaturschlüssel und die Releases vom 21. Oktober wurden laut Alpine gegen externe Aufzeichnungen geprüft und nicht manipuliert.
CVE-2026-97229: Was GitLab-Admins jetzt tun sollten
- Version prüfen und aktualisieren: Mindestens 19.4.2, 19.3.5 oder 19.2.8 einspielen, besser die aktuelle Version des jeweiligen Zweigs. Die Release-Notes erwähnen Datenbankmigrationen, Single-Node-Instanzen müssen mit Downtime rechnen.
- Ruby-Version kontrollieren: Wer GitLab aus dem Quellcode oder mit eigenem Container-Image betreibt, braucht zusätzlich Ruby 3.3.13, 3.4.12 oder 4.0.9 beziehungsweise neuer. Genau das wurde Alpine zum Verhängnis.
- Auf Spuren prüfen: Die sechs von GitLab veröffentlichten Erkennungen helfen, Angriffsversuche zu finden. Auffällige Worker-Abstürze, Fehler beim CI-Lint und ungewöhnliche Pipeline-Konfigurationen neuer Konten sind Warnsignale.
- Bei Verdacht wie bei einer Kompromittierung handeln: Nach unserer Einschätzung lohnt der Blick auf Alpines Liste möglicher betroffener Daten: CI/CD-Variablen, Runner-Tokens, Webhook- und Mirror-Zugangsdaten sowie 2FA-Secrets. Diese sollten im Zweifel rotiert werden.
- Angriffsfläche verkleinern: Im Alpine-Fall nutzte der Angreifer ein neu registriertes Konto. Offene Registrierungen zu beschränken ersetzt kein Update, reduziert aber die Zahl möglicher Angreifer.
Auch abseits von GitLab lohnt ein Blick in den eigenen Code: Jede Ruby-Anwendung, die Muster aus Nutzereingaben kompiliert, sollte auf eine gefixte Ruby-Version wechseln. Das Muster erinnert an andere Lieferketten-Probleme der letzten Wochen, etwa den LiteLLM-Supply-Chain-Angriff oder die npm-Dependency-Confusion-Welle mit 14 Paketen: Die Schwachstelle sitzt nicht im eigenen Code, sondern in einer Komponente darunter. Wie schnell solche Lücken in Web-Frameworks kritisch werden, zeigte zuletzt auch die Laravel-Lücke im TokenGuard.
Einordnung
CVE-2026-97229 ist kein neuer Fund, aber die Aufnahme in den KEV-Katalog verändert die Lage. Zwischen Patch am 12. Oktober und Angriffsversuchen bei Alpine lag gut eine Woche, und der Vorfall zeigt eine Lücke, die viele Betreiber übersehen dürften: Bei GitLab ist die Korrektur an die mitgelieferte Ruby-Version gebunden. Wer offizielle Omnibus-Pakete oder Images nutzt und aktualisiert hat, ist nach heutigem Stand geschützt. Wer eigene Builds betreibt, sollte heute prüfen, welches Ruby wirklich läuft. Code-Hosting-Server sind ein lohnendes Ziel, denn dort liegen Quellcode, CI-Secrets und Deployment-Zugänge an einem Ort.
