KIungefiltert

· 4 Min. Lesezeit · Read in English

GitLab: CVSS-10-Lücke ohne Anmeldung wird ausgenutzt, und ein Patch reicht nicht

CISA führt die GitLab-Lücke CVE-2026-97229 (CVSS 10.0) als aktiv ausgenutzt. Alpine Linux wurde angegriffen. Eine zweite Regex-Lücke macht den Oktober-Patch unvollständig. Was Selbsthoster jetzt tun sollten.

SicherheitSelfhosting

Die US-Cybersicherheitsbehörde CISA hat die GitLab-Schwachstelle CVE-2026-97229 am 29. Oktober 2026 in ihren Katalog Known Exploited Vulnerabilities (KEV) aufgenommen. In dieser Liste landen nur Lücken, für die es Belege für echte Angriffe gibt. Die Bewertung liegt bei CVSS 10.0, dem Maximum auf der Skala, mit der die Schwere von Sicherheitslücken eingestuft wird. Das hatte ich auf X und im WhatsApp-Kanal schon gemeldet. Seitdem ist aber etwas Wichtiges dazugekommen: Wer im Oktober nur einmal gepatcht hat, ist womöglich immer noch angreifbar.

Was passiert ist

Laut GitLabs Sicherheitshinweis steckt der Fehler im Compiler für reguläre Ausdrücke (Regex, also Suchmuster für Text), den GitLab für CI/CD-Konfigurationen nutzt. CI/CD steht für die automatisierten Build- und Deploy-Pipelines. Ein präparierter Regex löst einen Ganzzahlüberlauf aus, also eine Rechnung, deren Ergebnis zu groß für den vorgesehenen Speicher ist und deshalb „umkippt“. Am Ende kann ein Angreifer ohne Anmeldung Code auf dem GitLab-Server ausführen. Laut Rapid7 liegt die Ursache in Onigmo, der Regex-Engine von Ruby.

Betroffen sind die GitLab Community Edition und die Enterprise Edition auf selbst betriebenen Servern. GitLab.com und GitLab Dedicated sind laut GitLab bereits gepatcht. Den Fix gab es am 12. Oktober in den Versionen 19.2.8, 19.3.5 und 19.4.2. Schon am Tag danach veröffentlichte Rapid7 einen Proof of Concept, also Code, der die Ausnutzbarkeit demonstriert.

Der Fall Alpine Linux

Wie The Hacker News und heise berichten, hat ein unbekannter Angreifer am 20. und 21. Oktober versucht, die Lücke auf dem GitLab-Server von Alpine Linux auszunutzen. Dafür nutzte er ein frisch registriertes Konto und schickte präparierte CI-Konfigurationen. Die GitLab-Worker stürzten dabei achtmal ab, viermal kam der Angreifer ein Stück weit in die Ausnutzung hinein. Spätere Versuche am 25. und 26. Oktober wurden blockiert.

Hier muss man Versuch und Erfolg sauber trennen. Alpine fand keinen Beleg, dass Code ausgeführt wurde, kann es aber auch nicht ausschließen. Ein erfolgreicher Angriff hinterließe keinen Absturz und keine Spur im Web-Log, und ein Teil der Logs vom Angriffstag fehlt. Alpine behandelte den Server deshalb als kompromittiert, baute ihn neu auf, setzte alle Passwörter zurück und tauschte GitLabs geheime Schlüssel aus. Die Paket-Builds vom 20. bis 24. Oktober stimmten mit Aufzeichnungen außerhalb von GitLab überein, und die Signaturschlüssel lagen nie auf dem Server.

Der lehrreichste Teil: Alpine hatte am 13. Oktober versehentlich auf 19.3.4 statt 19.3.5 aktualisiert. Auch das spätere Update auf 19.3.6 schloss die Lücke nicht. GitLabs Fix steckt nämlich in dem Ruby, das GitLab in seinen eigenen Linux-Paketen und offiziellen Images mitliefert. Alpines Image verwendete dagegen ein normales Ruby. Die gefixten Ruby-Versionen sind 3.3.13, 3.4.12 und 4.0.9.

Was sich seit dem Post geändert hat

Am 21. Oktober hat GitLab mit CVE-2026-110264 eine weitere Lücke geschlossen, ebenfalls CVSS 10.0. Auch sie ist ein Ganzzahlüberlauf im Regex-Compiler und erlaubt Code-Ausführung ohne Anmeldung. Betroffen sind laut GitLab alle Versionen ab 7.0. Behoben ist sie in 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 und 18.11.13. Mehrere Fachmedien, darunter eSecurity Planet, weisen darauf hin, dass die Patches vom 12. Oktober diese zweite Lücke nicht abdecken. Für CVE-2026-110264 habe ich keine Meldung über aktive Ausnutzung gefunden, auf der KEV-Liste steht nur CVE-2026-97229.

Zur Einordnung der Dringlichkeit: Für US-Bundesbehörden empfiehlt CISA, die Fixes bis zum 1. November 2026 einzuspielen. Das gilt formal nur für diese Behörden, ist aber ein guter Maßstab für alle anderen.

Was du jetzt tun solltest

  • Auf den aktuellen Stand gehen, nicht nur auf den ersten Fix. Also mindestens 19.5.1, 19.4.3, 19.3.6 oder 19.2.9, je nach Versionszweig. Damit sind beide Regex-Lücken abgedeckt.
  • Ruby prüfen, wenn du GitLab nicht über die offiziellen Pakete oder Images betreibst, etwa als Quellinstallation oder mit einem Distributions-Image. Ruby muss auf 3.3.13, 3.4.12, 4.0.9 oder neuer stehen. Wer das alpinelinux/gitlab-Image nutzt, sollte 19.3.6 neu ziehen. Erst der Build vom 27. Oktober enthält das gefixte Ruby.
  • Nach Spuren suchen. Gehäufte Worker-Abstürze, 502-Fehler und fehlgeschlagene CI-Jobs seit dem 12. Oktober sind Warnzeichen, ebenso neu registrierte Konten mit auffälligen CI-Konfigurationen. GitLab stellt für Selbsthoster eigene Erkennungsregeln bereit, darunter „Onigmo native worker crash“.
  • Bei Verdacht wie Alpine handeln. Lässt sich ein Erfolg nicht ausschließen, solltest du Passwörter, Personal Access Tokens, Runner-Tokens, CI/CD-Variablen und Webhook-Zugangsdaten rotieren.
  • Offene Registrierung überdenken. Bei Alpine reichte ein frisch angelegtes Konto. Wer keine öffentliche Registrierung braucht, sollte sie abschalten.

Meine Einordnung: Gefährlich ist hier nicht nur die Lücke selbst, sondern das falsche Gefühl von Sicherheit nach dem Patch. Ob du wirklich geschützt bist, zeigt nicht die GitLab-Versionsnummer allein. Es hängt auch davon ab, welches Ruby tatsächlich darunter läuft.

Quellen