CISA nahm CVE-2026-97229 am 29. Oktober 2026 in den Katalog „Known Exploited Vulnerabilities“ (KEV) auf und verwies auf Hinweise auf aktive Ausnutzung. Für selbstverwaltete GitLab-Installationen nennt GitLab konkrete Korrekturversionen. Wer eine eigene Ruby-Laufzeit verwendet, muss laut Alpine Linux auch diese aktualisieren: Ein GitLab-Update allein ließ die Laufzeit in Alpines eigener Installation verwundbar. CISA GitLab Alpine Linux
Was CVE-2026-97229 ermöglicht
GitLab beschreibt CVE-2026-97229 als Ganzzahlüberlauf im Compiler für reguläre Ausdrücke der CI/CD-Funktionen. Unter bestimmten Bedingungen kann ein speziell präparierter regulärer Ausdruck in einer CI/CD-Konfiguration laut GitLab nicht authentifizierten Angreifern die Ausführung beliebigen Codes auf dem GitLab-Server ermöglichen. GitLab bewertet die Schwachstelle mit CVSS 10.0.
Betroffene GitLab-Versionen und Korrekturen
GitLab nennt drei betroffene Zweige von Community Edition und Enterprise Edition. Die angegebenen Versionen beheben die Schwachstelle jeweils ab dem genannten Release:
| GitLab-Zweig | Betroffene Versionen | Korrigiert ab |
| 19.2 | Versionen vor 19.2.8 | 19.2.8 |
| 19.3 | Versionen vor 19.3.5 | 19.3.5 |
| 19.4 | Versionen vor 19.4.2 | 19.4.2 |
GitLab zufolge lief GitLab.com bereits mit einer korrigierten Version. Die Mandanten von GitLab Dedicated waren vor Veröffentlichung der Patch-Mitteilung aktualisiert worden. Für selbstverwaltete Installationen veröffentlichte GitLab außerdem sechs Erkennungsregeln, mit denen sich Hinweise auf Ausnutzungsversuche aufspüren lassen.
Wann ein GitLab-Update nicht ausreicht
Der Fall Alpine Linux zeigt, warum bei einer eigenen Ruby-Laufzeit auch deren Version geprüft werden muss. GitLabs Korrektur betrifft Ruby, das in den offiziellen GitLab-Paketen und -Images enthalten ist. Alpine verwendete in seinem eigenen Image eine separat bereitgestellte Ruby-Laufzeit. Das GitLab-Update auf 19.3.6 am 22. Oktober ließ diese Laufzeit daher ungepatcht.
Alpine nennt Ruby 3.3.13, 3.4.12 oder 4.0.9 und höher als korrigierte Versionen für Installationen mit eigener Ruby-Laufzeit. Laut Alpine enthielt ein am 27. Oktober erstelltes Image Ruby 3.3.13; ältere Tags und zuvor erstellte 19.3.6-Images blieben verwundbar. Wer GitLab aus dem Quellcode oder in einem eigenen Image betreibt, muss daher sowohl den GitLab-Zweig als auch die tatsächlich verwendete Ruby-Laufzeit berücksichtigen.
Was Alpine über den Angriff berichtete
Alpine schilderte am 28. Oktober einen Angriff auf seine GitLab-Instanz am 20. und 21. Oktober. Die Instanz lief damals mit GitLab 19.3.4. Ein neu angelegtes Konto übermittelte präparierte CI-Konfigurationen; dabei stürzten GitLab-Worker achtmal ab. In vier Fällen kam der Angreifer nach Alpines Darstellung bis in einen späteren Exploitschritt, bevor der nächste Schritt scheiterte.
Alpine fand keine Hinweise darauf, dass der Angreifer Code ausgeführt hatte, konnte einen erfolgreichen Zugriff aber nicht ausschließen. Ein erfolgreicher Exploit hätte laut Alpine möglicherweise keine Absturz- oder Webprotokoll-Spuren hinterlassen; außerdem fehlten einige Protokolle vom Angriffstag. Alpine behandelte die Instanz deshalb als kompromittiert und baute sie neu auf. Die Prüfungen ergaben nach Angaben der Distribution keine Manipulationen am aports-Repository, an Paketen oder an den Veröffentlichungen vom 21. Oktober. Am 29. Oktober nahm Alpine den Betrieb der GitLab-Instanz mit Version 19.3.7 wieder auf.
Für wen BOD 26-04 gilt
CISA zufolge gilt die Richtlinie BOD 26-04 ausschließlich für US-Bundesbehörden der zivilen Exekutive (FCEB). Anderen Organisationen empfiehlt die Behörde, Schwachstellen aus dem KEV-Katalog ebenfalls zu priorisieren.
