Kritische Warnung · Ruby und GitLab
Ruby Regexp: vier kritische Schwachstellen, aufgedeckt von GitLab.
Ein präparierter regulärer Ausdruck beschädigt beim Kompilieren den Speicher von Ruby, bis hin zur Codeausführung auf dem Server. GitLab ist betroffen, ebenso jede Ruby-Anwendung, die ein von Nutzern geliefertes Muster kompiliert. So finden Sie heraus, ob Sie betroffen sind, und so beheben Sie das Problem.
Aktualisiert am 23. Oktober 2026 · Quellen: ruby-lang.org, GitLab
Das Wichtigste in 60 Sekunden
Die Gefahr steckt in Regexp.new.
Angreifbar sind nur Anwendungen, die einen regulären Ausdruck aus einem Text kompilieren, den ein Angreifer kontrolliert.
Regexp.timeout schützt nicht.
Weder das Timeout von Ruby noch eine Längenbegrenzung des Musters stoppt diese Fehler: Sie schlagen beim Kompilieren zu.
GitLab: Aktualisieren Sie die Instanz.
GitLab bringt sein eigenes Ruby mit. Auf einer selbst gehosteten Instanz muss das GitLab-Paket aktualisiert werden.
Was passiert
Vier Speicherfehler beim Kompilieren regulärer Ausdrücke
Nummeriert und bewertet von GitLab, das sie in seinem Produkt behoben hat, bevor Ruby eigene Versionen veröffentlichte.
| CVE | Der Fehler | Erforderlicher Zugang | CVSS | GitLab behoben in |
|---|---|---|---|---|
| CVE-2026-89078 | Doppelte Speicherfreigabe im Muster-Parser | Ein GitLab-Konto | 9,9 | 19.4.1 · 23.09.2026 |
| CVE-2026-93577 | Ganzzahlüberlauf im Muster-Compiler | Ein GitLab-Konto | 9,9 | 19.4.1 · 23.09.2026 |
| CVE-2026-97229 | Ganzzahlüberlauf im Compiler, über die CI/CD-Konfiguration | Keiner | 10,0 | 19.4.2 · 12.10.2026 |
| CVE-2026-110264 | Ganzzahlüberlauf im Muster-Compiler. Betrifft GitLab 7.0 bis 19.5 | Keiner | 10,0 | 19.5.1 · 21.10.2026 |
Das Ruby-Team hat für diese Korrekturen noch keine eigenen CVE beantragt und erklärt, dies eventuell nachzuholen.
Wer betroffen ist
Ihr Ruby-Branch und was zu tun ist
Die Supportdaten jedes Branches stammen aus dem offiziellen Kalender von ruby-lang.org.
| Branch | Behoben in | Offizieller Support | Zu tun |
|---|---|---|---|
| 4.0 | 4.0.9 | Normale Wartung | Auf 4.0.9 aktualisieren |
| 3.4 | 3.4.12 | Normale Wartung | Auf 3.4.12 aktualisieren |
| 3.3 | 3.3.13 | Nur Sicherheit → 31.03.2027 | Auf 3.3.13 aktualisieren, eine ausnahmsweise veröffentlichte Version |
| 3.2 und älter | keine | Beendet seit 01.04.2026 | Mindestens auf 3.3 migrieren, idealerweise auf 3.4 oder 4.0 |
Ruby 3.2 erhält keinen Patch
In 2 Minuten prüfen
Schauen Sie an drei Stellen nach: Version, Code und GitLab
Die Version zeigt, ob Ruby gepatcht ist. Der Code zeigt, ob die Anwendung Muster kompiliert, die von außen kommen.
$ cat .ruby-version
$ grep -A1 'RUBY VERSION' Gemfile.lock
$ ruby -v
$ grep -rnE 'Regexp\.(new|compile)|/#\{' app lib
$ sudo gitlab-rake gitlab:env:info | grep -i version
Was LibWatch für Sie tut
Die Ruby-Version jedes Repositorys, jede Nacht erneut geprüft.
- Liest die in jedem Repository festgelegte Ruby-Version: .ruby-version, Gemfile.lock, .tool-versions oder mise.
- Zeigt an, wenn es eine neuere Version des Branches gibt und wenn der Branch nicht mehr unterstützt wird, wie Ruby 3.2.
- Prüft jede Nacht alles erneut, auch Projekte, die niemand anfasst.
Die Grenze: LibWatch ordnet diese CVE noch nicht der Ruby-Engine zu und überwacht nicht die Version Ihrer GitLab-Instanz. Prüfen Sie zusätzlich ruby -v in der Produktion.
Ihr Code bleibt bei Ihnen: LibWatch liest Ihre Abhängigkeitsdateien und speichert nur die Liste Ihrer Pakete. So funktioniert es →
Beheben
Drei Schritte, und der zweite wird oft vergessen
Nur ein Ruby-Update behebt alle vier Schwachstellen.
Ruby aktualisieren und dann Ihre Images neu bauen
Ändern Sie auch .ruby-version und die ruby-Zeile im Gemfile, und aktualisieren Sie dann die Gemfile.lock.
$ rbenv install 3.4.12 && rbenv local 3.4.12
$ bundle update --ruby
$ docker build --pull --no-cache -t mon-app:corrigee .
Alle Ruby-Prozesse neu starten
Puma, Sidekiq, Solid Queue… Ein Prozess, der vor dem Update gestartet wurde, läuft noch mit dem alten Ruby.
$ ps -eo pid,lstart,cmd | grep -E 'puma|sidekiq|solid'
Selbst gehostetes GitLab: das Paket aktualisieren
Auf 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 oder 18.11.13. Ein Update des System-Ruby behebt nicht das Ruby von GitLab.
$ sudo apt update && sudo apt install gitlab-ee
# Community Edition: gitlab-ce
Bis dahin
Wenn Sie nicht sofort aktualisieren können
Schützt
Keine Muster mehr kompilieren, die von Nutzern kommen
- — Für eine Textsuche reicht String#include?: Es wird kein Muster kompiliert.
- — Bieten Sie für einen Filter eine Liste vordefinierter Muster statt eines Freitextfelds an.
# statt
lignes.grep(Regexp.new(params[:q]))
# besser
lignes.select { _1.include?(params[:q]) }
Schützt nicht
Was nicht schützt
- — Regexp.timeout: Die Fehler schlagen beim Kompilieren zu, vor jeder Ausführung.
- — Die Länge des Musters begrenzen: laut Ruby-Team nicht zuverlässig.
Nur das Update behebt das Problem
Chronologie
Ein Monat, von der ersten CVE bis zum Patch von Ruby
23.09.2026
GitLab 19.4.1
Die ersten zwei CVE behoben, bewertet mit 9,9.
12.10.2026
GitLab 19.4.2
Eine CI/CD-Schwachstelle, ohne Konto ausnutzbar, bewertet mit 10.
21.10.2026
GitLab 19.5.1
Die letzte CVE, GitLab 7.0 bis 19.5, bewertet mit 10.
23.10.2026
Ruby 4.0.9, 3.4.12, 3.3.13
Die Patches kommen in Ruby an, für alle Anwendungen.
Häufige Fragen