GitLab CVE-2026-97229: von CISA als ausgenutzt gelistet – und Alpine Linux zeigt, dass ein Update nicht immer genügt

CISA hat CVE-2026-97229, eine GitLab-Lücke mit CVSS 10.0, in ihren Katalog ausgenutzter Schwachstellen aufgenommen. Alpine Linux berichtet von einem Angriffsversuch auf den eigenen Server, der nach einem Update verwundbar blieb, weil die Korrektur auch von der eingesetzten Ruby-Version abhängt.

Was geschah

Am 29. Oktober 2026 nahm CISA CVE-2026-97229 in ihren Katalog ausgenutzter Schwachstellen auf. US-Bundesbehörden müssen bis zum 1. November handeln und eine forensische Prüfung durchführen. GitLab stuft die Lücke als kritisch ein, mit einem CVSS-Wert von 10,0: Ein Ganzzahlüberlauf im Compiler für reguläre Ausdrücke der CI/CD-Konfiguration erlaubt es einem nicht angemeldeten Benutzer unter bestimmten Bedingungen, Code auf dem Server auszuführen. GitLab behob den Fehler am 12. Oktober in 19.4.2, 19.3.5 und 19.2.8. Alpine Linux teilte am 28. Oktober mit, ein Angreifer habe am 20. und 21. Oktober versucht, ihn auf dem GitLab-Server des Projekts auszunutzen.

Wer betroffen ist und wie Angreifer eindringen

Betroffen sind selbst verwaltete Community- und Enterprise-Editionen ab 19.2; GitLab.com und Dedicated sind bereits gepatcht. Der Fehler steckt in Onigmo, der in Ruby eingebauten Engine für reguläre Ausdrücke, und GitLabs Korrektur ändert das Ruby in den offiziellen Paketen und Images. Alpine installierte zunächst versehentlich 19.3.4 und dann 19.3.6 in einem Image mit Standard-Ruby, das die Korrektur nicht enthielt. Mit einem neuen Konto und präparierten CI-Konfigurationen brachte der Angreifer GitLab-Prozesse achtmal zum Absturz. Alpine fand keinen Beleg für eine Codeausführung, konnte sie aber nicht ausschließen, baute den Server daher neu auf, setzte alle Passwörter zurück und ersetzte die geheimen Schlüssel von GitLab. Laut dem Projekt wurden Releases und Pakete geprüft und nicht verändert; Signaturschlüssel lagen nie auf diesem Server.

Was jetzt zu tun ist

1. Version prüfen mit sudo gitlab-rake gitlab:env:info.
2. Aktualisieren auf den neuesten Patch Ihres Zweigs: 19.5.3, 19.4.5, 19.3.7 oder 19.2.10.
3. Wenn Sie GitLab selbst bauen (aus dem Quellcode oder im eigenen Container), ruby -v prüfen: Nötig sind 3.3.13, 3.4.12, 4.0.9 oder neuer. alpinelinux/gitlab:19.3.6 erneut laden, falls vor dem 27. Oktober bezogen; ältere Tags sind verwundbar.
4. Nach Spuren suchen: die sechs von GitLab veröffentlichten Erkennungsregeln anwenden und Prozessabstürze, 502-Fehler, fehlgeschlagene CI-Jobs und neu registrierte Konten prüfen. Ein unauffälliges Ergebnis beweist wenig: Laut Alpine hinterlässt ein erfolgreicher Angriff weder einen Absturz noch eine Spur in den Webprotokollen.
5. Im Zweifel neu aufbauen und geheime Schlüssel, Passwörter, CI/CD-Variablen, Runner-Tokens und Webhook-Geheimnisse ersetzen. Neue Konten nur nach Freigabe durch einen Administrator zulassen.
6. Andere Ruby-Anwendungen prüfen: Code, der nicht vertrauenswürdige Eingaben an Regexp.new, Regexp.union oder ein interpoliertes Muster übergibt, braucht ein gepatchtes Ruby. Laut dem Ruby-Team schützen weder Regexp.timeout noch eine Längenbegrenzung zuverlässig.

Unsere Einschätzung

Eine Versionsnummer beweist nicht, dass ein Server gepatcht ist, wenn die Korrektur in einer Abhängigkeit liegt: Die Prüfung muss den gesamten Build umfassen, besonders bei eigenen Images. Eine Code-Plattform enthält Quellcode und Deployment-Geheimnisse und sollte nicht für das gesamte Internet offenstehen. Bewahren Sie genügend Protokolle auf, auch zu ausgehenden Verbindungen, um die Frage nach einer Kompromittierung beantworten zu können.

Quellen

• GitLab — Critical Patch Release: 19.4.2, 19.3.5, 19.2.8
• CISA — Known Exploited Vulnerabilities Catalog: CVE-2026-97229
• Alpine Linux — GitLab security incident: attempted exploitation of CVE-2026-97229
• Alpine Linux — GitLab is back: what you need to do
• Ruby — Regexp fixes for GitLab CVEs
• GitLab — Patch Release 19.5.3

Wie wir unsere Analysen auswählen, prüfen und schreiben →