Angriff auf den GitLab-Server von Alpine Linux über CVE-2026-97229: warum das GitLab-Update die Schwachstelle nicht geschlossen hat

Die kritische Schwachstelle CVE-2026-97229 (CVSS 10.0) in der in Ruby integrierten Regex-Engine Onigmo wurde für einen Angriff auf den GitLab-Server des Projekts Alpine Linux ausgenutzt. Laut Alpine Linux sendete ein neu registriertes Konto am 20.–21. Oktober 2026 speziell präparierte CI-Konfigurationen an den Server gitlab.alpinelinux.org. Das zentrale Problem: Das Update von GitLab auf Version 19.3.6 beseitigte die Schwachstelle nicht, da das Alpine-Image das Standard-Ruby und nicht das gepatchte Ruby aus den offiziellen GitLab-Paketen verwendete. Administratoren selbst kompilierter GitLab-Installationen und benutzerdefinierter Container-Images müssen sowohl GitLab als auch Ruby auf Version 3.3.13, 3.4.12 oder 4.0.9 aktualisieren. Die Schwachstelle wurde am 29. Oktober 2026 in den CISA-KEV-Katalog aufgenommen. Wir haben bereits früher über diese Schwachstelle geschrieben.

Wesen der Schwachstelle

Dem CVE-Eintrag zufolge handelt es sich bei CVE-2026-97229 um einen Ganzzahlüberlauf (CWE-190) im Regex-Compiler Onigmo, den Ruby zur Verarbeitung von Regex verwendet. GitLab kompiliert reguläre Ausdrücke aus CI/CD-Konfigurationen mithilfe von Ruby, wodurch ein Angreifer durch einen speziell präparierten regulären Ausdruck in der Datei .gitlab-ci.yml eine Ausführung beliebigen Codes auf dem Server erreichen kann.

Die Schwachstelle betrifft GitLab CE/EE in den Versionen:

• 19.2 bis 19.2.8
• 19.3 bis 19.3.5
• 19.4 bis 19.4.2

Rapid7 reproduzierte die vollständige Exploit-Kette auf dem offiziellen Image GitLab 19.4.1 CE und erreichte die Ausführung von Befehlen im Kontext des Systembenutzers git. Auf dem gepatchten Image 19.4.2 funktionierte dieselbe Eingabe nicht mehr. Ein wichtiges Detail: Im von Rapid7 getesteten Pfad muss der Angreifer zunächst eine bösartige CI-Konfiguration und eine Datei mit UTF‑8‑Zeichen im Pfad in einem öffentlichen Projekt platzieren – nur die abschließende CI-lint-Anfrage ist nicht authentifiziert. Diese Voraussetzung entfällt auf Servern, auf denen sich neue Benutzer selbst registrieren und Projekte anlegen können.

Chronologie des Angriffs auf Alpine Linux

Laut Alpine Linux entwickelte sich der Vorfall wie folgt:

• 13. Oktober – Alpine aktualisierte den Server auf GitLab 19.3.4 statt auf 19.3.5 (Fehler beim Update). Der Server blieb ohne den am 12. Oktober veröffentlichten Fix.
• 20.–21. Oktober – ein neu registriertes Konto sendete speziell präparierte CI-Konfigurationen und löste acht Abstürze von GitLab-Arbeitsprozessen aus. In vier Fällen kam der Angreifer in der Exploit-Kette teilweise voran, führte den nächsten Schritt jedoch nicht aus. Der Angriff am 21. Oktober verursachte zudem 502-Fehler und Ausfälle von CI-Jobs.
• 22. Oktober – Alpine aktualisierte den Server auf GitLab 19.3.6, die Schwachstelle blieb jedoch bestehen (das Standard-Ruby wurde nicht aktualisiert).
• 23. Oktober – das Konto des Angreifers wurde gesperrt.
• 25.–26. Oktober – der Angreifer versuchte erfolglos, den Zugang wiederherzustellen.
• 26. Oktober – Alpine stellte fest, dass der Server nach dem GitLab-Update weiterhin verwundbar war.
• 27. Oktober – der Server wurde für alle außer Entwicklern und Build-Servern gesperrt.
• 28. Oktober – der Server wurde komplett von Grund auf mit Ruby 3.3.13 neu aufgebaut, alle geheimen Schlüssel wurden ersetzt, die Passwörter aller Konten zurückgesetzt.

Alpine hielt außerdem fest, dass der Angreifer das Container-Image des GitLab-Projekts heruntergeladen hat, was nach Einschätzung von Alpine auf die Vorbereitung eines Exploits für den konkreten Build hinweist.

Warum das GitLab-Update nicht geholfen hat

Dies ist die zentrale Lehre aus dem Vorfall. Der GitLab-Fix vom 12. Oktober enthielt ein gepatchtes Ruby innerhalb der offiziellen Linux-Pakete und Container-Images von GitLab. Alpine verwendete jedoch ein eigenes Image mit dem System-Ruby anstelle des Ruby aus den GitLab-Paketen. Das Update von GitLab betrifft ein separat installiertes Ruby nicht – der verwundbare Regex-Compiler Onigmo bleibt unverändert bestehen.

Damit ist die Grenze des Fixes zweidimensional: Offizielle GitLab-Pakete enthalten ein gepatchtes Ruby, während selbst kompilierte Installationen und benutzerdefinierte Container-Images ein separates Ruby-Update erfordern. Die gefixten Ruby-Versionen – 3.3.13, 3.4.12 und 4.0.9 – erschienen am 22.–23. Oktober. Gleichzeitig wies mit Stand 29. Oktober keiner der GitLab-Sicherheitshinweise für selbst kompilierte Installationen auf die Notwendigkeit eines Ruby-Updates hin, und die Anleitung zur Installation aus dem Quellcode nannte weiterhin Ruby 3.2 als Mindestversion. Ruby 3.2 hat im April 2026 das Ende seines Lebenszyklus erreicht und wird keinen Fix erhalten – Nutzer dieses Zweigs müssen auf eine unterstützte Version migrieren.

Was festgestellt werden konnte – und was nicht

Alpine fand keine Hinweise auf eine Codeausführung durch den Angreifer: Zeitmessungen zeigten keine Verzögerungen, es wurden keine fremden Dateien, Schlüssel, Hooks oder Prozesse entdeckt. Alpine kann eine erfolgreiche Ausnutzung jedoch nicht ausschließen. Wie im Bericht des Projekts ausgeführt, hinterlässt ein erfolgreicher Exploit weder einen Absturz noch Spuren in den Weblogs. Ein Teil der Logs der Angriffstage ging verloren, darunter die Logs von Hintergrundaufgaben und das Dateisystem des alten Containers. Weder Alpine noch der Hosting-Provider führten ein Protokoll ausgehender Netzwerkverbindungen.

Das Fehlen ausgehender Telemetrie und unvollständige Logs sind die Schlüsselfaktoren, die eine saubere Forensik verhinderten. Dies erhöht die Bedeutung der von GitLab für selbst verwaltete Instanzen veröffentlichten sechs Erkennungsregeln und hostbasierter Prüfungen.

Bei einer erfolgreichen Ausnutzung hätten kompromittiert werden können: E-Mail-Adressen, Namen und IP-Adressen der Benutzer; Passwort-Hashes; 2FA-Geheimnisse; CI/CD-Variablen und Runner-Tokens; Zugangsdaten von Webhooks, Integrationen und Mirrors; Hashes persönlicher Zugriffstokens; private Repositories und vertrauliche Issues. Alpine betont, dass Paket- und Release-Signaturschlüssel nie auf dem GitLab-Server gespeichert wurden und alle Änderungen an aports im Angriffszeitraum anhand externer Aufzeichnungen verifiziert wurden.

Empfehlungen

Für GitLab-Administratoren

• Offizielle Linux-Pakete oder Container-Images von GitLab: Aktualisieren Sie auf das neueste Release für Ihren Zweig (19.4.2, 19.3.5, 19.2.8 oder neuer – die Releases vom 21. Oktober schließen außerdem die separate Schwachstelle CVE-2026-110264).
• Selbst kompilierte Installationen oder Images mit eigenem Ruby: Aktualisieren Sie sowohl GitLab als auch Ruby auf 3.3.13, 3.4.12 oder 4.0.9. Ruby 3.2 wird keinen Fix erhalten.
• Übergangsmaßnahmen (empfohlen von Rapid7): Beschränken Sie anonymen Zugriff auf öffentliche Projekte, verbieten Sie nicht vertrauenswürdigen Benutzern das Anlegen öffentlicher Projekte, blockieren Sie die CI-lint-Route. Diese Schritte schließen nur den von Rapid7 getesteten Exploit-Pfad.
• Erkennung: Nutzen Sie die sechs Erkennungsregeln von GitLab im Sigma-Format. Prüfen Sie auf Dateien des Benutzers git in /tmp, unerwartete Kindprozesse von Puma oder Sidekiq, ausgehende Verbindungen, geänderte crontab oder SSH-Schlüssel des Benutzers git.
• Wenn Sie Hinweise auf Codeausführung finden, betrachten Sie den Server als kompromittiert und rotieren Sie die Secrets in gitlab-secrets.json, alle CI/CD-Variablen, Runner-Tokens und Zugriffstokens.

Für Nutzer von Alpine Linux

• Nutzer des Images alpinelinux/gitlab sollten den Tag 19.3.6 erneut herunterladen – das Image vom 27. Oktober enthält Ruby 3.3.13, frühere Downloads sind verwundbar.
• Die Ruby-Pakete in Alpine sind bereits gefixt: Ruby 3.4.12 auf Alpine 3.22–3.24 und edge, Ruby 3.3.13 auf Alpine 3.21. Ein apk upgrade genügt.
• Besitzer von Konten auf gitlab.alpinelinux.org müssen ihr Passwort zurücksetzen, sobald der Server wieder geöffnet wird. Wurde dasselbe Passwort auf anderen Websites verwendet, sollte es auch dort geändert werden.

Der Vorfall bei Alpine Linux zeigt ein konkretes und reproduzierbares Szenario: Ein GitLab-Update ohne Ruby-Update lässt den Server für CVE-2026-97229 verwundbar. Administratoren selbst kompilierter Installationen und benutzerdefinierter GitLab-Container-Images müssen umgehend die Ruby-Version auf ihren Servern prüfen und auf 3.3.13, 3.4.12 oder 4.0.9 aktualisieren – ein GitLab-Update allein schließt diese Schwachstelle nicht.