GitLab CVE-2026-97229 in der CISA-KEV: Update allein reicht nicht

Hinweis: Dieser Beitrag wurde mit KI-Unterstützung erstellt und automatisiert veröffentlicht.

Die GitLab Sicherheitslücke CVE-2026-97229 steht seit dem 29. Oktober 2026 im Katalog der bekannt ausgenutzten Schwachstellen (KEV) der US-Behörde CISA. Der Eintrag hat eine ungewöhnlich kurze Frist: US-Bundesbehörden müssen bis zum 1. November 2026 reagieren. Brisant ist aber ein anderer Punkt — bei manchen selbst gehosteten Servern schließt das GitLab-Update die Lücke gar nicht.

GitLab CVE-2026-97229: Das ist der Stand

Die Schwachstelle hat laut NVD den CVSS-Wert 10.0, den Höchstwert. Ein nicht angemeldeter Angreifer kann unter bestimmten Bedingungen Code auf dem GitLab-Server ausführen — über einen speziell gebauten regulären Ausdruck in einer CI/CD-Konfiguration. Ursache ist eine unzureichende Prüfung beim Kompilieren solcher Muster.

• Betroffen: GitLab CE und EE ab 19.2 vor 19.2.8, ab 19.3 vor 19.3.5 und ab 19.4 vor 19.4.2 (Quelle: NVD).
• Behoben: GitLab-Releases vom 12. Oktober 2026 (19.2.8, 19.3.5, 19.4.2). GitLab.com und GitLab Dedicated sind bereits gepatcht.
• Neu seit 29. Oktober: CISA-KEV-Eintrag, Frist 1. November 2026.

Entdeckt hat den Fehler Johan Carlsson über GitLabs Bug-Bounty-Programm. Er ist einer von vier GitLab-CVEs, die alle in derselben Komponente stecken — Rubys Regex-Engine Onigmo.

AD-Checkliste

Dein AD härten: 12 Sofortmaßnahmen

Das PDF mit Bordmitteln, PowerShell-Prüfbefehlen und 30-Tage-Reihenfolge – per Mail, sobald du deine Anmeldung zum Tech-&-Tacheles-Newsletter bestätigst.

E-Mail-Adresse *

Mit der Anmeldung erhältst du die AD-Checkliste als PDF und danach den Tech-&-Tacheles-Newsletter mit Einordnungen zu Security, KI und Crypto sowie gelegentlichen Hinweisen auf meine Bücher und Produktempfehlungen (auch Affiliate-Links) – eingetragen bist du erst nach Klick auf den Bestätigungslink in der E-Mail (Double-Opt-in). Ich werte aus, ob du den Newsletter öffnest und Links anklickst, um ihn zu verbessern. Abmeldung jederzeit über den Link in jeder E-Mail, Details in der Datenschutzerklärung.

Warum ein GitLab-Update allein nicht reicht

Der eigentliche Fehler steckt nicht im GitLab-Code, sondern in Onigmo, der Regex-Engine von Ruby. GitLab kompiliert die regulären Ausdrücke aus CI-Konfigurationen mit Ruby. Der Fix besteht deshalb aus Patches für genau jenes Ruby, das GitLab in seinen eigenen Linux-Paketen und offiziellen Container-Images mitliefert.

Die Folge: Wer GitLab mit einem eigenen Ruby betreibt — selbst kompiliert oder in einem selbst gebauten Container-Image —, bekommt diesen Patch nicht. Dort braucht es zusätzlich Ruby 3.3.13, 3.4.12, 4.0.9 oder neuer. Die Ruby-Entwickler haben diese Versionen erst am 23. Oktober veröffentlicht, also elf Tage nach dem GitLab-Release. Ruby 3.2 ist seit April am Ende seines Lebenszyklus und bekommt den Fix nicht.

Ruby weist außerdem darauf hin, dass Regexp.timeout gegen diese Fehlerklasse nicht schützt und dass eine Längenbegrenzung der Muster ebenfalls nicht zuverlässig hilft. Betroffen ist jede Anwendung, die reguläre Ausdrücke aus fremder Eingabe kompiliert — nicht nur GitLab.

Der Fall Alpine Linux zeigt die Lücke in der Lücke

Das Alpine-Linux-Projekt hat den Ablauf am 28. Oktober offengelegt. Eine Woche nach dem Patch, am 20. und 21. Oktober, schickte ein neu registriertes Konto manipulierte CI-Konfigurationen an die Projekt-Instanz — die lief noch auf 19.3.4 und hatte den Fix vom 12. Oktober nicht, weil das Projekt am 13. Oktober versehentlich auf 19.3.4 statt 19.3.5 aktualisiert hatte. Acht Mal stürzten GitLab-Worker-Prozesse ab, in vier Fällen kam der Angreifer ein Stück weit durch und scheiterte erst am nächsten Schritt des Exploits. Er lud auch das GitLab-Container-Image des Projekts herunter — offenbar, um den Angriff auf diesen exakten Build abzustimmen.

Alpine aktualisierte am 22. Oktober auf GitLab 19.3.6 — und stellte am 26. Oktober fest, dass die Instanz weiterhin angreifbar war, weil das eigene Image Standard-Ruby nutzte. Das Projekt hat den Server anschließend von Null neu aufgebaut, alle Passwörter zurückgesetzt und die Schlüssel ersetzt. Ein erfolgreicher Angriff lässt sich nicht ausschließen, weil ein geglückter Exploit laut Alpine keinen Absturz und keine Spur in den Web-Logs hinterlässt und Logs des Angriffstags fehlten. Signierschlüssel lagen nie auf dem Server; die Pakete und die Releases vom 21. Oktober wurden gegen externe Aufzeichnungen geprüft und als unverändert bestätigt.

Was das für dich bedeutet

Aus CISO-Sicht ist dieser Fall lehrreicher als die reine CVE-Meldung. Drei Punkte fallen mir auf, die über GitLab hinausgehen.

Erstens: „Gepatcht“ ist eine Annahme, kein Zustand. Alpine hat am 22. Oktober auf eine Version aktualisiert, die den Fix laut Versionsnummer enthielt — und war trotzdem offen, weil der Fix in einer Komponente lag, die das eigene Build mitbringt. Genau dieses Muster kenne ich aus 25 Jahren Betrieb: Die Versionsnummer der Anwendung stimmt, die verwundbare Bibliothek darunter ist eine andere. Wer eigene Images baut, übernimmt damit auch die Pflicht, jede Security-Release auf Patches an mitgelieferten Komponenten zu lesen.

Zweitens: Selbstregistrierung ist eine Angriffsfläche. Der Angriff lief über ein frisch angelegtes Konto. Auf Instanzen, auf denen sich jeder registrieren und Projekte anlegen kann, entfällt eine Hürde, die der Exploit sonst braucht.

Drittens: Fehlende Logs kosten mehr als der Vorfall. Nicht der Angriff hat Alpine den Neuaufbau aufgezwungen, sondern die fehlende Nachweisbarkeit — keine Logs ausgehender Verbindungen, Hintergrund-Logs weg. Wer das nicht mitschreibt, muss im Zweifel immer vom schlimmsten Fall ausgehen.

Konkret auf deine Liste für diese Woche, wenn du GitLab selbst betreibst:

• Installationsart feststellen. Offizielles Linux-Paket oder offizielles Container-Image: auf den neuesten Release deines Branches aktualisieren, fertig. Selbst kompiliert oder eigenes Image: zusätzlich ruby -v auf dem Server prüfen und auf 3.3.13, 3.4.12 oder 4.0.9 heben.
• Version 19.3.4 gezielt suchen. GitLab nannte sie anfangs als behoben und listet sie inzwischen als betroffen — wer damals aktualisierte, hält sich für sicher und ist es nicht.
• Nach Spuren sehen: Dateien des git-Nutzers in /tmp, unerwartete Kindprozesse von Puma oder Sidekiq, geänderte Crontabs oder SSH-Schlüssel, Ruby-Abstürze mit Onigmo-Bezug. GitLab hat dafür Erkennungsregeln im Sigma-Format veröffentlicht.
• Zugang einschränken: Selbstregistrierung und das Anlegen von Projekten durch Unbekannte begrenzen, bis die Instanz sicher gepatcht ist.
• Logging nachziehen: ausgehende Verbindungen des GitLab-Hosts mitschreiben und die Aufbewahrung über 14 Tage hinaus verlängern — genau die Lehre, die Alpine selbst gezogen hat.

Wenn du GitLab oder vergleichbare Dienste zu Hause oder im Kleinbetrieb betreibst, lohnt ein Blick auf meinen Ratgeber zu NAS und Heimserver fürs Selfhosting — Hardware, die Updates ohne Ausfallfenster überhaupt zulässt, ist der unterschätzte Teil dieser Geschichte. Zum Thema selbst gehostetes GitLab passt auch der frühere Beitrag zur Lücke im GitLab AI Gateway (CVE-2026-90970).

Quellen

• CISA – Known Exploited Vulnerabilities Catalog (Eintrag CVE-2026-97229, aufgenommen 29.10.2026, Frist 01.11.2026)
• NVD – CVE-2026-97229 (CVSS 10.0, betroffene Versionen)
• Alpine Linux – GitLab security incident: attempted exploitation of CVE-2026-97229 (28.10.2026)
• Ruby – Regexp compilation fixes related to GitLab’s CVEs (23.10.2026)
• GitLab – Patch Release 19.4.2, 19.3.5, 19.2.8
• The Hacker News – Attacker Tried to Exploit Alpine Linux’s GitLab (29.10.2026)