Kritische Warnung · Ruby und GitLab

  • CVSS bis 10
  • Codeausführung aus der Ferne
  • Behoben am 23.10.2026

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

Mit einer KI lesen .md-Version

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.

CVEDer FehlerErforderlicher ZugangCVSSGitLab 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.

BranchBehoben inOffizieller SupportZu 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

Das Supportende war am 1. April 2026: Der Branch erhält keine korrigierte Version mehr, weder für diese Schwachstellen noch für künftige.

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.

Die Ruby-Version
$ cat .ruby-version
$ grep -A1 'RUBY VERSION' Gemfile.lock
$ ruby -v
Zur Laufzeit kompilierte Muster
$ grep -rnE 'Regexp\.(new|compile)|/#\{' app lib
Ihre GitLab-Instanz
$ 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, Bundler und Docker
$ 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.

Prüfen
$ 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.

Omnibus (Debian / Ubuntu)
$ 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.
Ruby
# 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

Das Ruby-Team empfiehlt 4.0.9, 3.4.12, 3.3.13 oder neuer.

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

Was man uns seit dem 23. Oktober fragt

Ist meine Rails-Anwendung betroffen?
Nur wenn sie einen regulären Ausdruck aus einem Text kompiliert, den ein Nutzer kontrolliert: Regexp.new(params[…]) oder eine Interpolation in einem Literal. Suchen Sie diese Muster in Ihrem Code und aktualisieren Sie Ruby auf jeden Fall.
Warum stammen die CVE von GitLab und nicht von Ruby?
Die Schwachstellen wurden von joaxcar über das Bug-Bounty-Programm von GitLab gemeldet. GitLab hat sie nummeriert, bewertet und in seinem Produkt behoben, bevor Ruby eigene Versionen veröffentlichte. Das Ruby-Team hat für diese Korrekturen noch keine eigenen CVE beantragt und erklärt, dies eventuell nachzuholen.
Reicht Regexp.timeout nicht aus?
Nein. Die Fehler schlagen beim Kompilieren des Musters zu, vor jeder Ausführung: Weder das Timeout von Ruby noch eine Längenbegrenzung des Musters stoppt sie. Nur ein Update auf 4.0.9, 3.4.12, 3.3.13 oder neuer behebt sie.
Braucht LibWatch Zugriff auf meinen Code?
Nein. LibWatch liest Ihre Abhängigkeitsdateien und speichert nur die Liste Ihrer Pakete. 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.