In seinem Sicherheitshinweis führt Ruby aus, dass eine Anwendung nur dann betroffen ist, wenn sie einen regulären Ausdruck aus einer Zeichenkette kompiliert, die ein Angreifer kontrolliert. Das ist der Fall, wenn ein Programm eine solche Zeichenkette an Regexp.new, Regexp.union oder Regexp.compile übergibt oder sie per Interpolation in ein Muster einsetzt, etwa als /#{input}/. Anwendungen, die ausschließlich von den eigenen Entwicklern geschriebene Ausdrücke verwenden, sind nicht betroffen.

Die Korrekturen stecken in:

  • Ruby 4.0: Aktualisierung auf 4.0.9
  • Ruby 3.4: Aktualisierung auf 3.4.12
  • Ruby 3.3: Aktualisierung auf 3.3.13

3.4.12 und 3.3.13 sind die ersten Veröffentlichungen ihrer Reihe, die überhaupt eine der drei Korrekturen enthalten. Die zuvor in derselben Woche erschienene Version 4.0.8 enthält den Fix für CVE-2026-110264 nicht — 4.0-Nutzer sollten daher 4.0.9 installieren. Für Ruby 3.2 und älter gibt es keine Korrektur mehr: Die Reihe 3.2 erreichte am 1. April 2026 ihr Supportende, 3.2.11 war die letzte Ausgabe. Ruby empfiehlt den Wechsel auf 3.4 oder 4.0.

Wer nicht aktualisieren kann, soll dem Hinweis zufolge aufhören, reguläre Ausdrücke aus nicht vertrauenswürdigen Eingaben zu kompilieren. Zwei naheliegende Gegenmaßnahmen helfen nicht: Das Setzen von Regexp.timeout stoppt die Fehler nicht, und eine Längenbegrenzung der Muster ist unzuverlässig, weil auch kurze Muster die Fehler auslösen können.

GitLab kompiliert reguläre Ausdrücke, die von Nutzern stammen, etwa Muster in CI/CD-Konfigurationen. Zwischen dem 23. September und dem 21. Oktober vergab das Unternehmen vier CVEs und behob sie jeweils durch Ausliefern eines gepatchten Ruby. Die ersten beiden, offengelegt am 23. September, setzen jeweils ein angemeldetes Konto voraus und wurden mit 9,9 von 10 bewertet. Die beiden aus dem Oktober — CVE-2026-97229 am 12. und CVE-2026-110264 am 21. — benötigen kein Konto und erhielten die Höchstbewertung 10,0. CVE-2026-110264 betrifft jede GitLab-Version ab 7.0.

Alle vier Lücken meldete ein Forscher unter dem Pseudonym joaxcar über das Bug-Bounty-Programm von GitLab. Mit Stand 23. Oktober war keine der vier im Katalog bekannter ausgenutzter Schwachstellen (KEV) der CISA gelistet.

Für die eigenen Korrekturen hat Ruby keine CVE-Kennungen beantragt, „zumindest vorerst", und verweist Nutzer darauf, die Probleme über die vier GitLab-CVE-Nummern zu verfolgen. Das hinterlässt eine Lücke für alle, die nach CVE scannen: Die CVE-Einträge von GitLab nennen nur GitLab als betroffenes Produkt, ein Scanner, der diese Einträge gegen installierte Ruby-Versionen abgleicht, findet also keine Entsprechung. Ruby hat derartige Fehler früher durchaus als Schwachstelle behandelt und 2022 sowie 2024 CVE-Nummern für entsprechende Korrekturen vergeben — obwohl es seit Langem als unsicher gilt, reguläre Ausdrücke aus nicht vertrauenswürdigen Eingaben zu bauen. Die Dokumentation beschreibt nicht vertrauenswürdige Muster weiterhin nur als Risiko für Dienstblockaden. Ruby kündigte an, den Hinweis zu aktualisieren, falls doch CVE-Kennungen beantragt werden.

Selbst betriebene GitLab-Instanzen benötigen die Ausgabe, die CVE-2026-110264 behebt. GitLab lieferte sie am 21. Oktober aus und portierte sie bis Version 18.11.13 zurück:

  • 19.5.1
  • 19.4.3
  • 19.3.6
  • 19.2.9
  • 19.1.9
  • 19.0.10
  • 18.11.13

GitLab.com läuft nach Angaben des Unternehmens bereits auf der gepatchten Version; GitLab-Dedicated-Mandanten auf aktuellen internen Releases müssen nichts tun. Da GitLab eine eigene Ruby-Kopie mitliefert und dort gepatcht hat, genügt die Installation einer der korrigierten Versionen. Zusätzlich veröffentlichte GitLab Erkennungsregeln, mit denen Administratoren selbst betriebener Instanzen nach Anzeichen von Ausnutzungsversuchen suchen können.