GitLabs Korrektur besteht aus Patches für das Ruby, das GitLab in seinen eigenen Paketen und Container-Images ausliefert. Alpines GitLab-Image nutzte dagegen ein Standard-Ruby – die Aktualisierung des Servers auf GitLab 19.3.6 am 22. Oktober behob die Schwachstelle daher nicht. Wer GitLab mit eigenem Ruby betreibt, selbst kompiliert oder in einem eigenen Container-Image, für den gelte: „Ein Upgrade von GitLab reicht nicht aus", so Alpine. Solche Server benötigen zusätzlich Ruby 3.3.13, 3.4.12, 4.0.9 oder neuer; Nutzer des Images alpinelinux/gitlab müssen 19.3.6 erneut ziehen.

Der betroffene Server gitlab.alpinelinux.org beherbergt aports, das Repository, aus dem Alpines Pakete gebaut werden. Pakete, die zwischen dem 20. und 24. Oktober gebaut wurden, sowie die Veröffentlichungen vom 21. Oktober stammen nach Angaben von Alpine aus aports-Änderungen, die gegen Aufzeichnungen außerhalb von GitLab abgeglichen wurden. Zu diesen Releases gehören auch die minirootfs-Dateien, aus denen die offiziellen Alpine-Docker-Images gebaut werden. Alpine weitet die Prüfung auf den 27. Oktober aus, den Tag der Schließung des Servers. Die Schlüssel, mit denen Pakete und Releases signiert werden, lagen nie auf dem GitLab-Server.

Verlauf des Angriffs

Am 13. Oktober hatte Alpine den Server auf GitLab 19.3.4 statt auf 19.3.5 aktualisiert – das Projekt bezeichnet dies als Fehler. Auf dieser Version, ohne den Fix vom 12. Oktober, lief der Server noch, als am 20. Oktober ein neu registriertes Konto begann, ihn abzutasten.

Das Konto schickte am 20. und 21. Oktober präparierte CI-Konfigurationen an den Server. Diese brachten GitLab-Worker-Prozesse achtmal zum Absturz; der Hauptangriff am 21. Oktober verursachte zudem 502-Fehler und ließ CI-Jobs scheitern. In vier dieser Abstürze kam der Angreifer laut Alpine bis zu einem fortgeschrittenen Punkt des Exploits und scheiterte erst am nächsten Schritt. Der Angreifer lud außerdem Alpines GitLab-Container-Image herunter, was laut Alpine „darauf hindeutet, dass sie den Exploit auf unseren genauen Build abstimmten".

Am 23. Oktober sperrte Alpine das Konto. Am 25. und 26. Oktober kehrte der Angreifer zurück und versuchte erneut, Zugang zu erlangen; diese Versuche schlugen nach Angaben von Alpine fehl. Am 26. Oktober stellte Alpine fest, dass der Server trotz des Upgrades auf 19.3.6 vom 22. Oktober weiterhin verwundbar war. Tags darauf schloss das Projekt GitLab für alle außer den eigenen Entwicklern und Buildservern und begann mit dem Neuaufbau. Dieser wurde am 28. Oktober abgeschlossen. Alpine ersetzte zudem die geheimen Schlüssel von GitLab; der neu aufgebaute Server läuft mit Ruby 3.3.13 oder neuer, das den Fix enthält. Vor der Wiederfreigabe für die Öffentlichkeit wird der Server getestet.

Was ausgeschlossen werden kann – und was nicht

Alpine fand keinerlei Hinweise darauf, dass Code des Angreifers auf dem Server ausgeführt wurde: Timing-Proben zeigten keine Verzögerungen, es gab keine unerwarteten Dateien, Schlüssel, Hooks oder Prozesse, und es wurden über keine sichtbare Web- oder API-Anfrage private Daten an den Angreifer zurückgesendet. Sicher sein kann das Projekt jedoch nicht: „Ein erfolgreicher Exploit würde keinen Absturz und keine Spur in den Weblogs hinterlassen", erklärte Alpine. Ein Teil der Protokolle vom Angriffstag fehlt, darunter die Logs der Hintergrundjobs und das Dateisystem des alten Containers; weder Alpine noch der Hosting-Anbieter protokollierten ausgehende Netzwerkverbindungen.

Da die Beweise, die eine Codeausführung belegen könnten, nicht mehr existieren, behandelte Alpine den Server als kompromittiert und baute ihn neu auf, um jeden möglichen Brückenkopf zu entfernen. Bei einem erfolgreichen Angriff hätten offengelegt werden können:

  • E-Mail-Adressen, Namen und IP-Adressen aller Nutzer
  • Passwort-Hashes
  • 2FA-Geheimnisse, CI/CD-Variablen und Runner-Tokens
  • Zugangsdaten für Webhooks, Integrationen und Push-Mirrors
  • Persönliche Zugriffstokens, die als Hashes gespeichert sind
  • Private Repositories sowie vertrauliche Issues und Merge Requests

Über die Passwortrücksetzung und die neuen geheimen Schlüssel hinaus hat Alpine nicht mitgeteilt, ob Runner-Tokens, CI/CD-Variablen, Zugriffstokens oder Integrations-Zugangsdaten vom Server ersetzt wurden.

Zur Prüfung der Pakete bestätigte Alpine, dass jede zwischen dem 20. und 22. Oktober hinzugefügte aports-Änderung über einen protokollierten Push eines bekannten Entwicklers eintraf. Abgeglichen wurde dies mit Aufzeichnungen, die der Angreifer nach Darstellung des Projekts nicht erreichen konnte: einer Entwicklerkopie des Repositories und allen 45 Buildservern. Jedes zwischen dem 20. und 24. Oktober gebaute Paket stammt aus aports-Änderungen, wie sie auf git.alpinelinux.org veröffentlicht sind.

Warum das GitLab-Upgrade nicht half

GitLab kompiliert die regulären Ausdrücke in CI-Konfigurationen mit Ruby; der Fehler hinter CVE-2026-97229 liegt in Onigmo, der in Ruby eingebauten Regex-Engine. GitLabs Release vom 12. Oktober behob ihn durch Patches am Ruby innerhalb des GitLab-Linux-Pakets und der Container-Images. Rubys eigene fehlerbereinigte Versionen erschienen am 22. und 23. Oktober. Ein GitLab-Upgrade verändert das Ruby eines Servers nicht – eine GitLab-Installation auf Standard-Ruby bleibt also verwundbar, bis Ruby selbst aktualisiert wird. Die gepatchten Linux-Pakete und offiziellen Container-Images von GitLab enthalten das korrigierte Ruby; eine selbst kompilierte Installation oder ein Image, das Ruby separat installiert, wie es bei Alpine der Fall war, nicht.

Stand 29. Oktober weist keiner der beiden GitLab-Beiträge zu den Patch-Releases vom 12. und 21. Oktober Administratoren selbst kompilierter Installationen darauf hin, Ruby zu aktualisieren. GitLabs Anleitung zur Selbstkompilierung nennt weiterhin Ruby 3.2 als Mindestversion – Ruby 3.2 erreichte im April das Ende seines Lebenszyklus und erhält keinen Fix.

Welche Server betroffen sind

GitLabs Sicherheitshinweis zufolge hätte die Lücke „unter bestimmten Bedingungen" einem nicht authentifizierten Nutzer erlaubt, Code auf dem Server auszuführen. GitLab.com und GitLab Dedicated sind bereits gepatcht.

Rapid7 baute im Labor einen funktionierenden Exploit und veröffentlichte am 13. Oktober Proof-of-Concept-Code. Der Exploit führte Befehle als GitLabs git-Nutzer auf einem ungepatchten offiziellen GitLab-19.4.1-Image aus; dieselbe Eingabe lief auf dem gepatchten 19.4.2-Image nicht. Der Exploit setzt zunächst Schreibzugriff voraus: Der Angreifer muss eine bösartige .gitlab-ci.yml sowie einen Dateipfad mit UTF-8-Zeichen in einen Branch eines öffentlichen Projekts committen. Diese Hürde entfällt auf Servern, auf denen sich neue Nutzer selbst registrieren und Projekte anlegen können. Auf dem von Rapid7 getesteten Weg sei „nur die abschließende CI-Lint-Anfrage unauthentifiziert". Auch GitLabs eigene Erkennungshinweise besagen, dass der Angreifer diesen Dateipfad zuvor über gewöhnliche Repository-APIs anlegen muss. Wie der Angriff aus der ursprünglichen, weiterhin nicht öffentlichen Meldung an GitLab den Schreibschritt umgeht, ist Rapid7 bislang unbekannt. Alpine hat nicht mitgeteilt, wie die CI-Konfigurationen des Angreifers zu GitLab gelangten oder ob neue Konten auf dem Server öffentliche Projekte anlegen konnten.

In CISAs Katalog bekannter ausgenutzter Schwachstellen war CVE-2026-97229 zum Stand der Aktualisierung vom 28. Oktober nicht enthalten.

Was Administratoren tun sollten

GitLabs Releases vom 21. Oktober sind die jeweils neuesten der betroffenen Zweige und beheben zusätzlich CVE-2026-110264, eine separate Regex-Schwachstelle. Welches Release hilft, hängt von der Installationsart ab:

  • GitLab-Linux-Paket oder offizielle Container-Images: Upgrade auf das neueste Release des jeweiligen Zweigs.
  • Selbst kompilierte Installationen oder Images mit eigenem Ruby: GitLab aktualisieren und Ruby auf 3.3.13, 3.4.12, 4.0.9 oder neuer heben. Ruby 3.2 erhält keinen Fix.

GitLabs Sicherheitshinweis nannte bei Veröffentlichung am 12. Oktober die Version 19.3.4 als behobene Fassung des 19.3-Zweigs. Inzwischen nennt er 19.3.5 und führt 19.3.4 als betroffen – Server auf 19.3.4 sollten auf 19.3.6 wechseln.

Ist ein sofortiges Upgrade nicht möglich, empfiehlt Rapid7, den anonymen Zugriff auf öffentliche Projekte einzuschränken, nicht vertrauenswürdigen Nutzern das Anlegen oder Beschreiben öffentlicher Projekte zu verwehren oder die CI-Lint-Route zu blockieren. Diese Schritte deckten nur den von Rapid7 erprobten Angriffsweg ab und behöben nicht den verwundbaren Regex-Compiler, so das Unternehmen.

GitLab hat sechs Erkennungsregeln im Sigma-Format für Ausnutzungsversuche gegen selbstverwaltete Server veröffentlicht. Vier davon, von GitLab als experimentell gekennzeichnet, suchen nach feindlichen Mustern in CI-Regexp-Warnungen und GraphQL-ciLint-Anfragen, nach ungewöhnlich langen Dateipfaden mit Nicht-ASCII-Zeichen sowie nach Ruby-Absturzberichten, die auf Onigmo verweisen. Die begleitende Anleitung warnt, dass ein erfolgreicher Exploit keinen Absturz hinterlassen kann, und nennt weitere Schritte: nach Dateien des git-Nutzers in /tmp suchen, nach unerwarteten Kindprozessen von Puma oder Sidekiq, nach ausgehenden Verbindungen sowie nach veränderten Crontabs oder SSH-Schlüsseln des git-Nutzers. Bei Anzeichen für Codeausführung sei der Server als kompromittiert zu behandeln und die Geheimnisse in gitlab-secrets.json, alle CI/CD-Variablen, alle Runner-Tokens und alle Zugriffstokens zu rotieren. Zudem solle eingeschränkt werden, wer Konten und persönliche Zugriffstokens anlegen darf.

Was Alpine-Nutzer tun sollten

Kontoinhaber müssen nach Angaben von Alpine beim Wiederöffnen von gitlab.alpinelinux.org über „Passwort vergessen?" auf der Anmeldeseite ein neues Passwort setzen. Alpine beobachtete außerdem automatisierte Anmeldeversuche gegen sein GitLab mit anderswo geleakten Passwörtern; wer sein gitlab.alpinelinux.org-Passwort auch andernorts verwendet hat, sollte es dort ändern.

Nutzer des Images alpinelinux/gitlab sollten alpinelinux/gitlab:19.3.6 erneut ziehen. Das am 27. Oktober veröffentlichte Image enthält Ruby 3.3.13; jedes zuvor gezogene 19.3.6-Image und alle älteren Tags sind verwundbar. Alpines eigene Ruby-Pakete enthalten den Fix bereits: Ruby 3.4.12 auf Alpine 3.22, 3.23, 3.24 und edge sowie Ruby 3.3.13 auf Alpine 3.21; ein apk upgrade installiert ihn.

Rubys Maintainer weisen darauf hin, dass der Fehler nur für Programme relevant ist, die einen regulären Ausdruck aus vom Angreifer kontrolliertem Text kompilieren, und dass Rubys Einstellung Regexp.timeout nicht davor schützt.