Alpine Linux stellt GitLab nach kritischen Ruby-Regex-Angriffsversuch neu auf

Alpine Linux gab am 28. Oktober bekannt, dass der GitLab-Server vollständig neu aufgebaut und jedes Benutzerpasswort zurückgesetzt wurde, nachdem ein gezielter Angriff eine kritische Schwachstelle ausgenutzt hatte. Der Vorfall verdeutlicht eine gefährliche Lücke in den Patch-Prozeduren für selbst verwaltete Instanzen, bei denen die zugrunde liegende Ruby-Laufzeitumgebung auch nach dem Aktualisieren der GitLab-Anwendung selbst verwundbar bleibt.

Was passiert ist

Ein Angreifer versuchte, CVE-2026-97229 auszunutzen, eine Schwachstelle mit einem perfekten CVSS-Score von 10.0, auf Alpinens eigenem GitLab-Instance, das das aports-Repository hostet. Die Schwachstelle ermöglicht Remote Code Execution (RCE) durch präparierte reguläre Ausdrücke in CI-Konfigurationen. Obwohl Alpine keine eindeutigen Beweise dafür fand, dass der Angreifer Code erfolgreich ausgeführt hat, konnte dies aufgrund fehlender Logs und der Art des Exploits nicht ausgeschlossen werden. Daher behandelten sie den Server als kompromittiert, schalteten ihn am 27. Oktober ab und schlossen den vollständigen Neuaufbau am 28. Oktober ab.

Der Angriff begann am 20. Oktober, nur eine Woche nachdem GitLab einen Fix veröffentlicht hatte. Ein neu registriertes Konto sondierte den Server und sendete bösartige CI-Konfigurationen, die Worker-Prozesse achtmal zum Absturz brachten. Am 21. Oktober verursachte der Angreifer 502-Fehler und CI-Job-Ausfälle. Alpine blockierte das Konto am 23. Oktober, aber der Angreifer kehrte am 25. und 26. Oktober zurück. Entscheidend war, dass Alpine am 26. Oktober feststellte, dass ihr Upgrade auf GitLab 19.3.6 am 22. Oktober die Schwachstelle nicht tatsächlich behoben hatte, da ihre Installation ein Standard-System-Ruby anstelle der gepatchten Version verwendete, die in GitLabs offiziellen Paketen enthalten ist.

Wie es funktioniert

Die Ursache liegt in Onigmo, der regulären Expression Engine, die in Ruby integriert ist. CVE-2026-97229 ist ein Fehler in dieser Engine, der durch spezifische Regex-Muster ausgelöst werden kann, die ein Angreifer in einer CI-Konfigurationsdatei bereitstellt. Wenn GitLab diese Konfigurationen verarbeitet, kompiliert es den Regex unter Verwendung von Ruby. Wenn die Ruby-Version verwundbar ist, kann dieser Kompilierungsschritt zu Remote Code Execution führen.

GitLab adressierte dies im Release vom 12. Oktober, indem der Ruby-Interpreter gepatcht wurde, der in seinen offiziellen Linux-Paketen und Container-Images enthalten ist. Viele Administratoren, einschließlich des Alpine-Teams, betreiben GitLab jedoch auf Basis ihres eigenen systeminstallierten Rubys oder benutzerdefinierter Container-Images. In diesen Setups aktualisiert das Upgrade des GitLab-Anwendungscodes nicht den zugrunde liegenden Ruby-Interpreter. Da der Fix in der Ruby-Sprache selbst liegt, bleiben Server, die unverpatchte Ruby-Versionen ausführen, unabhängig von der installierten GitLab-Version exponiert. Alpinens Image verwendete Standard-Ruby, sodass ihr GitLab-Upgrade die verwundbare Engine intakt ließ, bis sie Ruby explizit auf Version 3.3.13, 3.4.12 oder neuer aktualisierten.

Wichtige Details

• Schwachstelle: CVE-2026-97229 (CVSS 10.0) in Rubys Onigmo-Regex-Engine.
• Angriffsvektor: Präparierte reguläre Ausdrücke in .gitlab-ci.yml-Dateien, die über CI-Konfiguration eingereicht wurden.
• Patch-Lücke: Das bloße Upgrade von GitLab reicht für selbst kompilierte Installationen oder benutzerdefinierte Images nicht aus; Ruby selbst muss auf 3.3.13, 3.4.12, 4.0.9 oder neuer aktualisiert werden.
• Vorfalls-Zeitplan: Angriffs-Sondierungen begannen am 20. Oktober; Server geschlossen am 27. Oktober; Neuaufbau abgeschlossen am 28. Oktober.
• Datenrisiko: Potenzielle Exposition umfasst Benutzer-E-Mail-Adressen, Passwort-Hashes, 2FA-Geheimnisse, CI/CD-Variablen und private Repositories, falls Codeausführung stattfand.
• Verifizierung: Alpine verifizierte die Paketintegrität vom 20. bis 24. Oktober gegen externe Aufzeichnungen und bestätigte, dass kein Supply-Chain-Kompromiss in den gebauten Paketen vorlag.

Warum es wichtig ist

Dieser Vorfall dient als deutliche Erinnerung für Engineering-Teams, die selbst gehostete Infrastruktur verwalten. Er deckt eine häufige Blindstelle im Dependency Management auf: die Annahme, dass das Aktualisieren einer Anwendung automatisch deren Laufzeitumgebung absichert. Für Entwickler, die Produkte mit KI oder komplexen CI/CD-Pipelines bauen, ist das Verständnis der Unterscheidung zwischen Anwendungs-Level-Patches und Runtime-Level-Patches entscheidend. Das Versäumnis, den zugrunde liegenden Sprachinterpreter zu aktualisieren, kann ein System kritischen Exploits weit offen lassen, selbst wenn der Anwendungsanbieter behauptet, das Problem sei gelöst.

Darüber hinaus unterstreicht die Mehrdeutigkeit des Ergebnisses die Schwierigkeit forensischer Analysen in Cloud-nativen Umgebungen. Da ein erfolgreicher Exploit dieser Natur möglicherweise keine traditionellen Spuren wie Abstürze oder Log-Einträge hinterlässt, müssen Organisationen einen Zero-Trust-Ansatz für Incident Response adoptieren. Alpinens Entscheidung, von Grund auf neu aufzubauen, statt zu versuchen, den Server zu bereinigen, illustriert die hohen operativen Kosten solcher Schwachstellen. Für technische Gründer und IT-Leads verstärkt dies die Notwendigkeit für robustes Logging, Immutable Infrastructure Practices und strenge Verifizierung aller Komponenten in der Software-Supply-Chain.

Was Sie tun können

• Überprüfen Sie Ihre Ruby-Version: Wenn Sie selbst kompiliertes GitLab oder benutzerdefinierte Container betreiben, stellen Sie sicher, dass Ruby sofort auf 3.3.13, 3.4.12, 4.0.9 oder neuer aktualisiert wird.
• Überprüfen Sie GitLab-Upgrades: Stellen Sie sicher, dass Ihre GitLab-Installationsmethode das gepatchte Ruby bündelt. Falls nicht, aktualisieren Sie das System-Ruby manuell.
• Rotieren Sie Secrets: Wenn Sie eine Exposition vermuten, rotieren Sie alle CI/CD-Variablen, Runner-Tokens, Personal Access Tokens und Webhook-Credentials.
• Einschränken Sie Zugriff: Begrenzen Sie anonymen Zugriff auf öffentliche Projekte und verhindern Sie, dass nicht vertrauenswürdige Benutzer öffentliche Repositories erstellen oder beschreiben.
• Überwachen Sie Indikatoren: Nutzen Sie GitLabs veröffentlichte Sigma-Detection-Regeln, um nach feindlichen Regex-Mustern, ungewöhnlich langen Dateipfaden mit Nicht-ASCII-Zeichen und Ruby-Crash-Reports zu suchen.
• Aktualisierte Images ziehen: Wenn Sie Alpinens GitLab-Image verwenden, ziehen Sie alpinelinux/gitlab:19.3.6 erneut, um sicherzustellen, dass es nach dem 27. Oktober veröffentlicht wurde, um das fixe Ruby einzuschließen.