GitLab CE und EE: CVE-2026-97229 schließt eine kritische Schwachstelle im CI/CD-Compiler (CVSS 10.0). CISA führt die Lücke seit 29. Oktober im KEV-Katalog; für Self-Managed-Instanzen besteht dringender Handlungsbedarf.
Auf einen Blick: Akute Bedrohungslage
  • Maximaler Schweregrad CVSS 10.0: Unauthentisierte Remotecode-Ausführung über präparierte Regular Expressions in CI/CD-Konfigurationen möglich.
  • Aktive Ausnutzung bestätigt: Am 29. Oktober 2026 durch CISA in den KEV-Katalog aufgenommen; Angriffsversuche gegen ungepatchte Instanzen dokumentiert.
  • Bereinigte Versionen: GitLab CE/EE 19.4.2, 19.3.5 und 19.2.8.
  • Sonderfall Ruby & eigene Container: Bei Custom-Builds muss zwingend auch die gepatchte Ruby-Komponente (3.3.13, 3.4.12 oder 4.0.9+) aktualisiert werden.
Ablauf und Abhilfe für GitLab CVE-2026-97229
Ablauf und Schutzmaßnahmen für GitLab CVE-2026-97229: Unzureichende Regex-Validierung im CI/CD-Compiler erfordert sofortige Patches und Prüfung eigener Container-Builds.

1. Executive Summary

CVE-2026-97229 ist eine kritische Schwachstelle im CI/CD-Regular-Expression-Compiler von GitLab CE und EE. GitLab und der CVE-Record bewerten sie mit CVSS v3.1 10.0 (Critical): Unter bestimmten Bedingungen kann eine speziell präparierte reguläre Expression in einer CI/CD-Konfiguration unauthentisierte Ausführung beliebigen Codes auf dem GitLab-Server ermöglichen. [1] [2]

Die Bedrohungslage ist akut: CISA nahm die CVE am 29. Oktober 2026 aufgrund nachgewiesener aktiver Ausnutzung in den Known Exploited Vulnerabilities Catalog auf. Alpine Linux dokumentierte am 30. Oktober einen Angriff gegen seine damals ungepatchte GitLab-Instanz; Codeausführung wurde dort nicht nachgewiesen, konnte wegen unvollständiger Telemetrie aber nicht sicher ausgeschlossen werden. [3] [4] [5]

2. Betroffene Systeme & Versionsmatrix

Betroffen sind GitLab Community Edition und Enterprise Edition in folgenden Versionsbereichen, unabhängig vom Deployment-Typ (Omnibus, Helm, Source oder Docker): [1]

GitLab Zweig Verwundbare Versionen Bereinigter Patch-Stand Status
GitLab 19.4 19.4.0 bis vor 19.4.2 19.4.2 Bereinigt
GitLab 19.3 19.3.0 bis vor 19.3.5 19.3.5 Bereinigt
GitLab 19.2 19.2.0 bis vor 19.2.8 19.2.8 Bereinigt
GitLab.com / Dedicated Bereits herstellerseitig gepatcht Aktueller Stand Sicher
Achtung bei eigenen Ruby- oder Container-Builds: Alpine Linux stellte bei seinem Incident fest, dass das GitLab-Upgrade allein nicht genügte, weil die Umgebung nicht GitLabs gepatchte, gebündelte Ruby-Komponente verwendete. Für Custom-Setups gelten als bereinigte Ruby-Zielstände: 3.3.13, 3.4.12 oder 4.0.9 und neuer. [5]

3. Technischer Angriffsvektor

GitLab beschreibt die Ursache als unzureichende Validierung regulärer Ausdrücke im CI/CD-Compiler. Eine speziell präparierte Regex in einer CI/CD-Konfiguration kann einen Integer Overflow auslösen und dadurch unter bestimmten Bedingungen Codeausführung auf dem GitLab-Server ermöglichen. [1] [2]

Der offizielle CVSS-Vektor lautet CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Er beschreibt einen Netzwerkangriff mit geringer Komplexität, ohne Privilegien und ohne Nutzerinteraktion; Vertraulichkeit, Integrität und Verfügbarkeit sind maximal exponiert. Entscheidend ist, ob nicht vertrauenswürdige CI/CD-Konfigurationen in der Instanz (z. B. über Forks, Branches oder offene Registrierung) verarbeitet werden können.

Im Alpine-Fall nutzte ein neu registriertes Konto präparierte CI-Konfigurationen gegen GitLab 19.3.4. Acht Worker-Crashes wurden beobachtet, bei vier Versuchen kam der Angreifer laut Alpine teilweise durch die Exploit-Kette. Alpine fand keinen Beleg für erfolgreiche Codeausführung, behandelte die Instanz wegen der verbleibenden Unsicherheit dennoch als potenziell kompromittiert und baute sie vollständig neu auf. [5]

4. Status der Ausnutzung & CISA KEV

Aktiv in freier Wildbahn ausgenutzt: Ja. Die KEV-Aufnahme durch CISA vom 29. Oktober 2026 ist die maßgebliche Bestätigung. Der Status für bekannte Ransomware-Kampagnen wird derzeit mit „Unknown“ geführt. [3] [4]

Für US-Bundesbehörden setzt CISA eine sehr kurze Frist bis zum 1. November 2026. Dies ist ein unmissverständlicher Weckruf auch für europäische Betreiber: Bei Anzeichen einer Exposition vor dem Patch reicht ein reines Versionsupgrade als Reaktion nicht zwangsläufig aus; eine Triage der Systemintegrität ist dringend angeraten.

5. Sofortmaßnahmen & Patch-Anleitung

  1. Alle Self-Managed-Instanzen inventarisieren und reale Version prüfen:
    Prüfen Sie den Versionsstand Ihrer Instanz: 
    sudo gitlab-rake gitlab:env:info
sudo gitlab-rake gitlab:check
    Stellen Sie sicher, dass Sie mindestens 19.2.8, 19.3.5 oder 19.4.2 betreiben.
  2. Unverzüglich auf einen bereinigten GitLab-Release aktualisieren:
    Nutzen Sie das offizielle Paket-Upgrade (z. B. via apt-get update && apt-get install gitlab-ee oder Helm Upgrade). Halten Sie Backups und Rollback-Pfade bereit.
  3. Eigene Images und Ruby gesondert verifizieren:
    Bei Source-Installationen oder Custom-Docker-Images prüfen Sie die Ruby-Version: 
    ruby --version
    Aktualisieren Sie mindestens auf Ruby 3.3.13, 3.4.12 oder 4.0.9+.
  4. GitLab-Detektionen aktivieren und Worker-Logs prüfen:
    Suchen Sie in den Logs nach Warnungen wie Onigmo native worker crash, Graphql cilint hostile regexp oder ci lint workhorse worker crash. Prüfen Sie neu angelegte Benutzerkonten und Pipelines im Zeitraum vor dem Patch.
  5. Bei Verdacht Incident-Prozess auslösen:
    Trennen Sie potenziell betroffene Systeme vom Produktivnetz. Rotieren Sie alle CI/CD-Geheimnisse, Runner-Tokens, Deploy-Keys und Webhook-Secrets.

6. Fazit & strategische Einordnung

GitLab CVE-2026-97229 betrifft das Herzstück moderner Software-Lieferketten. Das Risiko erschöpft sich nicht in einem Dienstausfall: Bei erfolgreicher Server-Kompromittierung stehen vertraulicher Quellcode, API-Tokens und Produktiv-Zugangsdaten auf dem Spiel.

Der operative Mindeststandard lautet: Self-Managed-GitLab zügig auf die bereinigten Releases 19.4.2, 19.3.5 oder 19.2.8 aktualisieren, Custom-Image- und Ruby-Sonderfälle (Ruby 3.3.13+, 3.4.12+, 4.0.9+) prüfen und ungewöhnliche Worker- oder CI-Lint-Ereignisse im Vorfeld des Patches forensisch bewerten. Die KEV-Aufnahme und die CVSS-10.0-Einstufung begründen für exponierte Instanzen ein unmittelbares Wartungsfenster.

7. Offizielle Quellen & Referenzen