Alpine Linux stellt GitLab nach Versuch eines kritischen Ruby-Regex-Angriffs neu auf

Am 20. und 21. Oktober griff ein Angreifer die GitLab-Instanz von Alpine Linux an und nutzte dabei eine kritische Schwachstelle im regulären Ausdrucks-Engine (Regex) von Ruby aus. Obwohl es keine Hinweise auf eine erfolgreiche Code-Ausführung gab, konnte das Team dies nicht ausschließen und entschied sich daher für einen vollständigen Neuaufbau des Dienstes, um die Integrität sicherzustellen.

Was passiert ist

Der Vorfall dreht sich um CVE-2026-97229, eine kritische Schwachstelle mit einem CVSS-Score von 10,0, die beeinflusst, wie GitLab reguläre Ausdrücke in CI-Konfigurationsdateien auswertet. Die Ursache liegt in Onigmo, der regulären Ausdrucks-Engine, die in Ruby eingebettet ist. GitLab veröffentlichte am 12. Oktober gepatchte Versionen, doch diese Fixes erforderten spezifische Patches für die gebündelte Ruby-Laufzeitumgebung und nicht Änderungen am eigentlichen GitLab-Anwendungscode. Alpine Linux führte am 13. Oktober versehentlich ein Upgrade auf GitLab 19.3.4 statt auf die korrigierte Version 19.3.5 durch, wodurch ihre Instanz exponiert blieb.

Zwischen dem 20. und 21. Oktober reichte ein neu registriertes Konto speziell präparierte CI-Konfigurationen ein, die darauf abzielen, die Schwachstelle auszulösen. Diese Payloads führten dazu, dass GitLab-Worker-Prozesse achtmal abstürzten. In vier dieser Fälle gelangte der Angreifer teilweise durch die Exploit-Kette, scheiterte jedoch am nächsten Schritt. Der Angreifer lud zudem das GitLab-Container-Image herunter, vermutlich um den Exploit gegen die spezifische Build-Umgebung anzupassen. Das Team beobachtete zwar keine Anzeichen einer erfolgreichen Code-Ausführung, wie etwa unerwartete Dateien oder Prozessverzögerungen, räumte jedoch ein, dass ein erfolgreicher Exploit in den Standard-Web-Logs keine Spuren hinterlassen würde.

Die Reaktion wurde dadurch erschwert, dass ein Upgrade auf GitLab 19.3.6 am 22. Oktober die Schwachstelle nicht behob. Da Alpinens Container-Image das Standard-Ruby anstelle des gepatchten Bundles von GitLab verwendete, blieb die zugrunde liegende Schwachstelle bestehen, bis Ruby selbst den Fix in den Versionen 3.3.13, 3.4.12 und 4.0.9 am 23. Oktober veröffentlichte. Als das Team am 26. Oktober feststellte, dass ihre Instanz weiterhin verwundbar war, sperrten sie den Zugang für alle außer Entwickler und begannen mit einem vollständigen Neuaufbau.

Wie es funktioniert

Diese Schwachstelle nutzt die Art und Weise aus, wie reguläre Ausdrücke von der Onigmo-Engine innerhalb von Ruby verarbeitet werden. Wenn GitLab CI-Konfigurationsdateien parst, kompiliert es diese regulären Ausdrücke. Wenn ein Angreifer ein böswillig präpariertes Muster bereitstellt, kann dies dazu führen, dass sich die Engine unvorhersehbar verhält, was potenziell Remote-Code-Ausführung ermöglicht. Dies ist kein Fehler in der Geschäftslogik von GitLab, sondern in der grundlegenden Sprach-Laufzeitumgebung, von der es abhängt.

Für selbst gehostete Instanzen entsteht dadurch eine komplexe Abhängigkeitskette. Ein einfaches Update der GitLab-Anwendung reicht nicht aus, wenn die Host-Umgebung eine systemweite Ruby-Installation verwendet, die nicht gepatcht wurde. Die offiziellen Pakete von GitLab enthalten ein gepatchtes Ruby, aber benutzerdefinierte Bereitstellungen oder Container-Images, die auf Upstream-Ruby setzen, müssen warten, bis die Maintainer der Sprache den Fix veröffentlichen. In diesem Fall kam der Fix erst mit den Ruby-Releases am 23. Oktober, mehr als eine Woche nach dem ursprünglichen Patch von GitLab.

Wichtige Details

• Schwachstelle: CVE-2026-97229 (CVSS 10,0) in Rubys Onigmo-Regex-Engine.
• Angriffszeitraum: 20.–21. Oktober, mit weiteren Versuchen am 25.–26. Oktober.
• Auswirkung: Acht Worker-Abstürze; kein bestätigter Datenabfluss, aber als Kompromittierung behandelt.
• Fehlgeschlagene Mitigation: Das Upgrade von GitLab auf 19.3.6 behebt das Problem nicht, da das zugrunde liegende Ruby ungepatcht war.
• Verifizierung: Alpine-Releases und -Pakete vom 20.–24. Oktober wurden gegen externe Aufzeichnungen überprüft und als unverändert befunden.
• Reaktion: Vollständiger Neuaufbau der Instanz, Zurücksetzen aller Passwörter und Implementierung von Logging für ausgehende Verbindungen.

Warum das wichtig ist

Dieser Vorfall beleuchtet eine kritische Blindstelle beim Management selbst gehosteter Infrastruktur: die Unterscheidung zwischen Patches auf Anwendungsebene und Fixes auf Laufzeitumgebungs-Ebene. Entwickler gehen oft davon aus, dass ein Upgrade des primären Softwarepakets alle damit verbundenen Sicherheitsrisiken beseitigt. Wenn jedoch Schwachstellen in gemeinsamen Abhängigkeiten wie Ruby, Python oder Node.js existieren, ist der Pfad zur Behebung fragmentiert. Teams müssen Patches über mehrere Ebenen hinweg verfolgen, einschließlich der Sprach-Laufzeitumgebung, der Betriebssystem-Pakete und der Anwendung selbst.

Für Engineering-Leads unterstreicht dies die Bedeutung der Überprüfung der Zusammensetzung von Container-Images und Deployment-Artefakten. Das Verlassen auf Standard-Systempakete kann zu Verzögerungen zwischen dem Fix eines Anbieters und der Sicherheitslage Ihrer Umgebung führen. Darüber hinaus erschwerte das Fehlen von Logging für ausgehende Netzwerkverbindungen die Untersuchung, was zeigt, dass die Sichtbarkeit auf Egress-Traffic genauso entscheidend ist wie das Monitoring von Ingress-Traffic, um Exfiltration oder Command-and-Control-Aktivitäten zu erkennen.

Was Sie tun können

• Überprüfen Sie sofort Ihre Ruby-Version; stellen Sie sicher, dass Sie 3.3.13, 3.4.12, 4.0.9 oder neuer verwenden, wenn Sie GitLab nutzen.
• Prüfen Sie Ihre GitLab-Container-Images; wenn Sie alpinelinux/gitlab:19.3.6 vor dem 27. Oktober bezogen haben, ziehen Sie es erneut, um das gepatchte Ruby zu erhalten.
• Auditiere Sie Ihre CI/CD-Pipelines auf kürzliche Änderungen oder fehlgeschlagene Jobs, die auf Versuche hinweisen könnten, die Schwachstelle auszunutzen.
• Aktivieren Sie das Logging für ausgehende Netzwerkverbindungen von Ihren CI-Servern und Datenbank-Hosts, um die Fähigkeiten zur Incident Response zu verbessern.
• Setzen Sie alle Passwörter zurück und rotieren Sie Secrets, einschließlich CI/CD-Variablen und Runner-Tokens, wenn Sie eine Exposition vermuten.
• Implementieren Sie signierte Release-Tags für Ihre internen Artefakte, um eine unabhängige Verifizierung der Build-Integrität zu ermöglichen.