Sadeem IT Solutions
30. Okt. 2026

GitLab-Lücke wird aktiv angegriffen: Warum das Update allein oft nicht reicht (CVE-2026-97229)

Eine GitLab-Lücke mit CVSS 10 wird aktiv angegriffen, die US-Behörde CISA führt sie seit dem 29. Oktober als ausgenutzt. Wer GitLab mit eigenem Ruby betreibt, muss zusätzlich Ruby aktualisieren.

gitlab-ci-luecke-aktiv-angegriffen-cve-2026-97229

Am 12. Oktober 2026 hat GitLab eine kritische Sicherheitslücke geschlossen: CVE-2026-97229, bewertet mit dem Höchstwert CVSS 10.0. Inzwischen ist aus der Warnung Ernst geworden. Angreifer haben versucht, den GitLab-Server des Linux-Projekts Alpine darüber zu übernehmen, und die US-Cybersicherheitsbehörde CISA hat die Lücke am 29. Oktober in ihren Katalog aktiv ausgenutzter Schwachstellen (KEV) aufgenommen.

Der Fall zeigt außerdem eine Falle, die viele übersehen: Das GitLab-Update allein schützt nicht in jedem Fall. Der Fehler steckt nicht in GitLab selbst, sondern in der Programmiersprache Ruby, auf der GitLab aufbaut.

Was ist passiert

GitLab wertet in CI/CD-Pipelines reguläre Ausdrücke (Regex) aus, also Suchmuster in der Konfigurationsdatei .gitlab-ci.yml. Die zuständige Regex-Engine heißt Onigmo und ist fester Bestandteil von Ruby. Ein präpariertes Suchmuster bringt dort einen Zahlenwert zum Überlaufen (Integer Overflow), der Speicher gerät durcheinander und ein Angreifer kann ohne Anmeldung eigenen Code auf dem GitLab-Server ausführen.

Die zeitliche Abfolge:

  • 12. Oktober: GitLab veröffentlicht die Versionen 19.4.2, 19.3.5 und 19.2.8 mit dem Fix.
  • 13. Oktober: Das Sicherheitsunternehmen Rapid7 kann den Angriff nachstellen, kurz darauf liegt ein öffentlicher Proof of Concept vor.
  • 20. bis 26. Oktober: Ein Angreifer registriert ein Konto auf dem GitLab-Server von Alpine Linux und lässt mit präparierten CI-Konfigurationen mehrfach Prozesse abstürzen. Laut Alpine kam er dabei teilweise weit. Alpine hatte zunächst versehentlich eine Version ohne Fix eingespielt und danach festgestellt, dass das eigene Container-Image ein separat installiertes Ruby nutzte, das weiter verwundbar war.
  • 21. Oktober: GitLab schließt mit 19.5.1, 19.4.3, 19.3.6 und 19.2.9 eine zweite Lücke mit CVSS 10 (CVE-2026-110264).
  • 23. Oktober: Das Ruby-Projekt veröffentlicht Ruby 4.0.9, 3.4.12 und 3.3.13 mit den Korrekturen.
  • 27. und 28. Oktober: Alpine baut seinen GitLab-Server komplett neu auf und tauscht alle Passwörter und Schlüssel. Manipulierte Pakete wurden nach Angaben des Projekts nicht gefunden.
  • 29. Oktober: CISA stuft die Lücke als aktiv ausgenutzt ein. US-Bundesbehörden müssen bis zum 1. November reagieren.

Wer ist betroffen

Betroffen sind selbst betriebene GitLab-Server (Community und Enterprise Edition) in den Versionen 19.2 bis 19.4 vor den oben genannten Fixes. GitLab.com und GitLab Dedicated sind bereits gepatcht.

Besonders gefährdet sind Instanzen, auf denen sich neue Nutzer selbst registrieren oder öffentliche Projekte anlegen können. Laut Rapid7 genügt dann ein gewöhnliches Konto für den Angriff.

Zusätzlich gilt:

  • Wer GitLab über die offiziellen Linux-Pakete oder Container-Images betreibt, erhält das korrigierte Ruby mit dem GitLab-Update.
  • Wer GitLab aus dem Quellcode installiert oder ein eigenes Image mit separatem Ruby nutzt, muss zusätzlich Ruby aktualisieren.
  • Auch andere Ruby-Anwendungen können betroffen sein, wenn sie Suchmuster aus Nutzereingaben zusammensetzen. Ein Regex-Timeout schützt laut Ruby-Projekt nicht.

Was Sie jetzt tun sollten

  1. Version prüfen: Im Admin-Bereich von GitLab oder per cat /opt/gitlab/embedded/service/gitlab-rails/VERSION auf dem Server.
  2. Auf eine aktuelle Version gehen: mindestens 19.4.3, 19.3.6 oder 19.2.9, besser die neueste Version Ihres Zweigs oder 19.5.x. Diese Stände schließen auch die zweite kritische Lücke CVE-2026-110264.
  3. Ruby prüfen, falls Sie GitLab selbst kompilieren oder ein eigenes Image bauen: mindestens Ruby 3.3.13, 3.4.12 oder 4.0.9. Ruby 3.2 wird nicht mehr gepflegt und sollte abgelöst werden.
  4. Container-Images neu ziehen: Ein gleichnamiger Tag kann ein veraltetes Image enthalten. Alpine weist ausdrücklich darauf hin, dass Images vor dem 27. Oktober betroffen waren.
  5. Angriffsfläche verkleinern: Selbstregistrierung abschalten oder Freigabe durch Admins verlangen, öffentliche Projekte und anonymen Zugriff einschränken. Das ersetzt das Update nicht, erschwert den bekannten Angriffsweg aber deutlich.
  6. Auf Spuren prüfen: Ungewöhnliche Abstürze von GitLab-Prozessen, fehlgeschlagene CI-Jobs mit seltsamen Konfigurationen und neue, unbekannte Konten seit dem 12. Oktober sind Warnzeichen. Im Verdachtsfall den Server als kompromittiert behandeln, neu aufsetzen und alle Tokens, Runner-Registrierungen und Zugangsdaten tauschen.
  7. Protokolle länger aufbewahren: Alpine konnte einen Erfolg des Angreifers nicht sicher ausschließen, weil Logs nur kurz gespeichert und ausgehende Verbindungen nicht protokolliert wurden.

Wie Sadeem hilft

Wir betreiben GitLab, Container und Linux-Server für mittelständische Unternehmen auf Infrastruktur in Deutschland und der EU. Dazu gehören zeitnahe Sicherheitsupdates, die Prüfung mitgelieferter Komponenten wie Ruby, Monitoring und Backups. Auf Wunsch prüfen wir Ihre GitLab-Instanz kurzfristig, spielen die Updates ein und richten Registrierung und Projektfreigaben sicher ein. Wenn Sie unsicher sind, ob Ihr Server betroffen ist, sprechen Sie uns gern im kostenlosen Erstgespräch an.

Quellen

SecurityGitLabCVE