GitLab-Schwachstelle überstand Upgrade auf Alpine-Server
Die GitLab-Schwachstelle CVE-2026-97229 blieb auf dem self-hosted Server von Alpine Linux auch nach einem GitLab-Upgrade ausnutzbar, weil das container des Projekts eine separate Ruby-Installation verwendete, die den mit GitLab gebündelten Patch nicht erhielt. Alpine teilte mit, dass ein Angreifer am 20. und 21. Oktober manipulierte Konfigurationen für continuous integration, kurz CI, einreichte. Das Projekt fand keinen Beleg dafür, dass Code ausgeführt wurde; aufgrund fehlender Nachweise konnte es eine erfolgreiche Kompromittierung jedoch nicht ausschließen.
CVE-2026-97229 hat im Common Vulnerability Scoring System, kurz CVSS, eine Bewertung von 10,0, den Höchstwert dieser Schweregradskala. Unter bestimmten Bedingungen kann eine bösartige regular expression, also ein Muster zur Textsuche, in einer CI-Konfiguration GitLab dazu bringen, vom Angreifer kontrollierten Code auszuführen. Der zugrunde liegende Fehler befindet sich in Onigmo, der in Ruby enthaltenen Engine für regular expression. GitLab verwendet Ruby, um Ausdrücke in CI-Dateien zu verarbeiten.
GitLab veröffentlichte seinen ersten Fix am 12. Oktober, indem es das Ruby änderte, das mit den eigenen Linux-Paketen und offiziellen container images gebündelt ist. Alpine aktualisierte seinen Server am 13. Oktober auf GitLab 19.3.4 statt auf 19.3.5, was Alpine als Fehler bezeichnete. Ein neu registriertes Konto begann am 20. Oktober damit, den weiterhin verwundbaren Server zu untersuchen. Die eingereichten Konfigurationen ließen GitLab worker processes innerhalb von zwei Tagen achtmal abstürzen. Der Hauptversuch am 21. Oktober verursachte außerdem 502-Fehler und unterbrach CI-Jobs. Alpine erklärte, vier Abstürze hätten gezeigt, dass der Exploit vor seinem Scheitern eine Zwischenstufe erreicht hatte. Das Konto lud außerdem das GitLab-container image von Alpine herunter, was darauf hindeutete, dass der Angreifer den Versuch an diesen speziellen Build anpasste.
Alpine sperrte das Konto am 23. Oktober. Versuche, am 25. und 26. Oktober zurückzukehren, scheiterten. Das Projekt stellte jedoch am 26. Oktober fest, dass sein Upgrade auf GitLab 19.3.6 vom 22. Oktober die Schwachstelle nicht geschlossen hatte. Das Image alpinelinux/gitlab installierte Standard-Ruby separat und enthielt daher nicht das gepatchte Ruby, das mit den eigenen Paketen und Images von GitLab ausgeliefert wurde. Alpine beschränkte den Dienst am 27. Oktober auf Entwickler und Build-Server und baute ihn anschließend vollständig neu auf. Der Neuaufbau wurde am 28. Oktober mit Ruby 3.3.13 oder neuer abgeschlossen; außerdem wurden die GitLab secret keys ersetzt und verpflichtende Passwortzurücksetzungen angeordnet. Alpine testete den neu aufgebauten Dienst, bevor er wieder öffentlich zugänglich gemacht werden sollte.
Alpine fand keine unerwarteten Dateien, Prozesse, hooks oder Zugangsdaten, und Timing-Tests zeigten nicht die bei den Untersuchungen erwarteten Verzögerungen. Es fand auch keine sichtbare Anfrage über das Web oder eine application programming interface, kurz API, durch die private Informationen an den Angreifer gesendet wurden. Diese Prüfungen waren nicht eindeutig. Alpine erklärte, ein erfolgreicher Versuch müsse weder einen Absturz noch eine Spur im Web-Log verursachen. Einige Logs von Hintergrund-Jobs sowie das frühere container-Dateisystem waren nicht verfügbar, und weder Alpine noch sein Hosting-Anbieter hatten ausgehende Verbindungen aufgezeichnet. Das Projekt behandelte den Server daher als kompromittiert, statt aus dem Fehlen von Belegen zu schließen, dass der Angriff gescheitert sei.
Falls Codeausführung stattgefunden hat, könnten unter anderem Benutzernamen, E-Mail- und IP-Adressen, password hashes, Geheimnisse für two-factor authentication, CI/CD variables, runner tokens, Zugangsdaten für Integrationen und webhooks, private repositories sowie vertrauliche Issues und merge requests offengelegt worden sein. Personal access tokens wurden als hashes gespeichert. Alpine hat nicht mitgeteilt, ob es neben der Zurücksetzung der Passwörter und dem Austausch der GitLab secret keys auch runner tokens, CI/CD variables, access tokens oder Zugangsdaten für Integrationen ersetzt hat.
Der betroffene Server hostet aports, das Repository, mit dem Alpine-Pakete erstellt werden. Alpine überprüfte jede vom 20. bis 22. Oktober hinzugefügte Änderung an aports anhand der Repository-Kopie eines Entwicklers und aller 45 Build-Server. Nach Angaben des Projekts konnte der Angreifer auf diese Aufzeichnungen nicht zugreifen. Alpine bestätigte, dass jede Änderung über einen aufgezeichneten push eines bekannten Entwicklers eingegangen war und dass die vom 20. bis 24. Oktober erstellten Pakete mit der auf git.alpinelinux.org veröffentlichten aports-Historie übereinstimmten. Die Prüfungen wurden bis zum 27. Oktober ausgeweitet. Zu den geprüften Releases gehörten die minirootfs-Dateien, die für die offiziellen Alpine Docker-Images verwendet werden. Package signing keys und release signing keys waren niemals auf dem GitLab-Server gespeichert worden.
Administratoren müssen zwischen den offiziellen GitLab-Paketen und Installationen unterscheiden, die ihr eigenes Ruby bereitstellen. Das Linux-Paket und die offiziellen container images von GitLab sollten auf das neueste Release ihres jeweiligen Branch aktualisiert werden. Die Releases vom 21. Oktober waren 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 und 18.11.13. GitLab führt 19.4.2, 19.3.5 und 19.2.8 als Versionen auf, die CVE-2026-97229 in den jeweils betroffenen Branches beheben. Der Sicherheitshinweis bezeichnete 19.3.4 ursprünglich als korrigiert, markiert die Version inzwischen jedoch als betroffen. Installationen, die noch 19.3.4 verwenden, sollten daher auf 19.3.6 wechseln. Die neueren Releases beheben außerdem CVE-2026-110264, eine separate Schwachstelle bei regular expression.
Selbst kompilierte Installationen und angepasste Images, die Ruby unabhängig installieren, müssen beide Komponenten aktualisieren. Korrigierte Ruby-Releases sind 3.3.13, 3.4.12 und 4.0.9 oder neuer. Ruby 3.2 erreichte im April das Ende seines Lebenszyklus und wird diese Korrektur nicht erhalten, obwohl der Installationsleitfaden von GitLab für selbst kompilierte Installationen die Version mit Stand vom 29. Oktober weiterhin als Mindestanforderung aufführte. Die Patch-Beiträge von GitLab vom 12. und 21. Oktober wiesen Administratoren selbst kompilierter Installationen nicht darauf hin, Ruby zu aktualisieren. Alpine-Benutzer sollten alpinelinux/gitlab:19.3.6 erneut herunterladen, da das am 27. Oktober veröffentlichte Image Ruby 3.3.13 enthält, während frühere Kopien dieses Tags und alle älteren Tags weiterhin verwundbar sind. Die Ruby-Pakete von Alpine enthalten 3.4.12 unter Alpine 3.22, 3.23, 3.24 und edge sowie 3.3.13 unter Alpine 3.21; mit apk upgrade werden sie installiert.
Rapid7 entwickelte einen funktionierenden Labor-Exploit und veröffentlichte am 13. Oktober proof-of-concept code. Damit wurden Befehle als GitLab-Benutzer git auf einem ungepatchten offiziellen GitLab-19.4.1-Image ausgeführt; gegen 19.4.2 scheiterte der Exploit jedoch. Dieser Angriffsweg erfordert, dass eine bösartige .gitlab-ci.yml-Datei und ein Pfad mit UTF-8-Zeichen in ein öffentliches Projekt committed werden, bevor die abschließende nicht authentifizierte CI-lint-Anfrage erfolgt. Diese Hürde gilt möglicherweise nicht in Umgebungen, in denen sich jeder registrieren und Projekte erstellen kann. Rapid7 weiß nicht, wie der weiterhin nicht öffentliche ursprüngliche Bericht den Schreibschritt umgeht, und Alpine hat nicht erklärt, wie der Angreifer seine Konfigurationen übermittelte. CVE-2026-97229 war mit Stand der Aktualisierung vom 28. Oktober nicht im Known Exploited Vulnerabilities-Katalog von CISA enthalten.
GitLab hat sechs Sigma-Erkennungsregeln für selbst verwaltete Server veröffentlicht, von denen vier als experimentell gekennzeichnet sind. Sie suchen nach verdächtigen CI-Warnungen, GraphQL-ciLint-Anfragen, ungewöhnlich langen Nicht-ASCII-Pfaden und Ruby-Absturzberichten mit Bezug zu Onigmo. Administratoren sollten außerdem temporäre Dateien, Child-Prozesse von Puma oder Sidekiq, ausgehende Verbindungen, geänderte geplante Aufgaben und veränderte SSH-Zugangsdaten untersuchen. Bei Hinweisen auf Codeausführung muss der Host als kompromittiert behandelt werden; GitLab-Geheimnisse, CI/CD variables, runner tokens und access tokens sollten ersetzt werden. Vorübergehende Beschränkungen für anonymen Zugriff, Schreibzugriffe auf öffentliche Projekte oder die CI-lint-Route decken nur den von Rapid7 demonstrierten Angriffsweg ab und reparieren Ruby nicht.