GitLab CVE-2026-97229: Alpine meldet einen Angriffsversuch

Alpine Linux meldet, dass ein Angreifer am 20. und 21. Oktober 2026 versucht hat, CVE-2026-97229 auf dem GitLab-Server des Projekts auszunutzen. Das war etwa eine Woche, nachdem GitLab einen Fix ausgeliefert hatte. Die größere Lehre steckt in Alpines Vorfallsbericht, veröffentlicht am 28. Oktober. Ein Upgrade von GitLab selbst schloss die Lücke in Alpines Setup nicht, weil der eigentliche Fix ein Patch für Ruby ist.

Alpine ist eine kleine Linux-Distribution, die als Basis für Docker-Container sehr beliebt ist. Die Entwickler nutzen einen selbst gehosteten GitLab-Server, um den Code für die Pakete zu verwalten.

Was auf Alpines Server passiert ist

Laut Alpine ließen die Versuche die Worker-Prozesse von GitLab achtmal abstürzen. Bei vier dieser Abstürze kam der Angreifer mit dem Exploit ein Stück weit voran.

Alpine sagt, es habe keine Hinweise darauf gefunden, dass der Angriff funktioniert hat. „Wir haben keine Hinweise darauf gefunden, dass er erfolgreich war, können es aber nicht ausschließen“, heißt es in dem Beitrag.

Deshalb behandelte das Team den Server als kompromittiert. Es baute GitLab von Grund auf neu auf und beschränkte den Zugang auf Entwickler und Build-Server. Außerdem setzte es alle Passwörter und geheimen Schlüssel zurück.

Das Projekt prüfte auch, was für seine Nutzer am wichtigsten ist. Laut Alpine wurden das aports-Repository, die Pakete und die stabilen Releases vom 21. Oktober mit externen Aufzeichnungen abgeglichen. Sie zeigten keine Anzeichen von Manipulation. Diese Releases waren Alpine 3.21.9, 3.22.7, 3.23.7 und 3.24.3. Die Schlüssel, mit denen Alpine-Pakete signiert werden, lagen nie auf dem GitLab-Server, und 45 Build-Maschinen wurden überprüft.

Alpine fand dabei noch ein weiteres Problem. Automatisierte Anmeldungen auf dem Server nutzten Passwörter, die von anderen Websites geleakt worden waren. Wer sein Alpine-GitLab-Passwort auch anderswo verwendet hat, sollte es dort ändern.

Warum das GitLab-Upgrade nicht half

Diesen Teil sollten andere Selbsthoster zweimal lesen. „Das Upgrade auf GitLab 19.3.6 am 22. Oktober hat die Schwachstelle nicht behoben“, schreibt Alpine.

Der Grund liegt darin, wie GitLab den Fix ausliefert. Die offiziellen Pakete von GitLab bringen eine eigene Kopie von Ruby mit, der Programmiersprache, in der GitLab geschrieben ist. Laut Alpine besteht der Fix für CVE-2026-97229 aus einer Reihe von Patches für dieses mitgelieferte Ruby. Alpine betreibt GitLab stattdessen mit dem Standard-Ruby, daher änderte eine neuere GitLab-Version allein nichts.

Alpine sagt außerdem, es habe das Update auf 19.3.5 am 13. Oktober versehentlich übersprungen. Während des Angriffs lief noch 19.3.4. Die eigenen ruby-Pakete von Alpine enthalten den Fix jetzt, und Alpine-Nutzer sollten apk upgrade ausführen.

Was CVE-2026-97229 ist

GitLab machte die Lücke am 12. Oktober 2026 öffentlich und forderte alle selbst verwalteten Installationen zum Upgrade auf. BleepingComputer berichtete, dass es sich um einen Integer-Überlauf in dem Teil von GitLab handelt, der reguläre Ausdrücke in CI/CD-Pipeline-Dateien liest. Reguläre Ausdrücke sind Textmuster, und CI/CD-Pipelines sind die Skripte, die Code automatisch bauen und testen. In GitLabs Sicherheitshinweis hieß es, der Fehler „hätte es einem nicht authentifizierten Nutzer ermöglichen können, beliebigen Code auf dem GitLab-Server auszuführen“.

Ein Forscher mit dem Handle „joaxcar“ meldete die Lücke über GitLabs Bug-Bounty-Programm auf HackerOne. GitLab.com war bereits gepatcht, und Kunden von GitLab Dedicated mussten nichts tun.

Punkt	Detail
Schweregrad	CVSS 10.0, der Höchstwert
Fehlertyp	Integer-Überlauf im CI/CD-Regex-Compiler
Korrigierte Builds	19.2.8, 19.3.4 oder 19.3.5 und 19.4.2 (Quellen uneinig bei 19.3)
Öffentlicher Exploit	Am 13. Oktober von Rapid7 veröffentlicht
Exponierte Hosts	25.766 mit verwundbaren Versionen, laut Censys

Die Quellen sind sich beim Fix für 19.3 uneinig. BleepingComputer nennt 19.3.4. Daily Security Review und Alpine verweisen beide auf 19.3.5. Prüfen Sie GitLabs eigenen Sicherheitshinweis für Ihren genauen Zweig.

Daily Security Review berichtete am 14. Oktober, dass der Exploit auf einer präparierten Datei beruht, die in einen Branch eines öffentlichen Projekts committet wird. Damals gab es keinen bestätigten Angriff in freier Wildbahn. Auch die US-Behörde für Cybersicherheit und Infrastruktursicherheit (CISA) hatte den Fehler nicht in ihre Liste ausgenutzter Schwachstellen aufgenommen. Censys stellte zudem fest, dass etwa 31 % der erkannten GitLab-Hosts noch ungepatcht waren.

Das ist GitLabs zweite Regex-Lücke mit maximalem Schweregrad in diesem Monat. GitLab 19.5.1 behob CVE-2026-110264, einen separaten Fehler mit CVSS 10.0, am 21. Oktober.

Was das für Entwickler bedeutet

Alpines Bericht macht aus einem bekannten Patch eine praktische Checkliste. Er zeigt auch, dass „wir haben aktualisiert“ und „wir sind sicher“ nicht dasselbe sind.

• Prüfen Sie, woher Ihr GitLab sein Ruby bezieht. Wenn Sie GitLab aus dem Quellcode oder aus Distributionspaketen mit dem System-Ruby betreiben, enthält das GitLab-Upgrade allein den Fix womöglich nicht. Stellen Sie sicher, dass Ihr Ruby die Patches enthält, so wie Alpine es tun musste.
• Überspringen Sie keine Point-Releases. Alpine hat 19.3.5 versehentlich verpasst. Richten Sie Ihren Upgrade-Prozess nach GitLabs Sicherheitshinweisen aus, nicht nach einem Routineplan.
• Gehen Sie davon aus, dass ein öffentlicher Server abgetastet wurde. Seit dem 13. Oktober gibt es einen öffentlichen Exploit. Wenn Sie danach einen verwundbaren Build im Internet betrieben haben, prüfen Sie die Absturzprotokolle der Worker aus den folgenden Wochen.
• Sichern Sie öffentliche Projekte ab. Der Exploit braucht eine präparierte Datei in einem öffentlichen Projekt. Bis Sie gepatcht haben, beschränken Sie, wer den Server erreichen kann, und deaktivieren Sie das Anlegen öffentlicher Projekte für nicht vertrauenswürdige Nutzer.
• Halten Sie Signaturschlüssel von der Code-Plattform fern. Alpine konnte sagen, dass seine Pakete sicher waren, weil die Signaturschlüssel nie auf GitLab lagen. Diese Designentscheidung ist es wert, kopiert zu werden.
• Setzen Sie wiederverwendete Passwörter zurück. Auch bei Alpine tauchten Anmeldungen per Credential Stuffing auf. Drängen Sie Nutzer zu eindeutigen Passwörtern und Zwei-Faktor-Anmeldung, bis diese überall eingeführt sind.