CVE-2026-97229 went on CISA's Known Exploited Vulnerabilities catalogue on 29 October, due 1 November, with forensic triage requested. GitLab scores it 10.0 and describes it as an unauthenticated user executing arbitrary code on the GitLab server through a specially crafted regular expression in a CI/CD configuration. The patch shipped on 12 October.

The entry names GitLab. The bug does not live there.

The bug is in Ruby

Ruby published a post on 23 October releasing 4.0.9, 3.4.12 and 3.3.13 to fix bugs in Onigmo, the regular expression engine Ruby has used for years. GitLab found the bugs, reported them upstream, and filed 4 CVEs against itself, each of which traces back to the same engine rather than to anything GitLab wrote:

  • CVE-2026-89078, a double free when parsing fails after an alternation, fixed in GitLab 19.4.1.
  • CVE-2026-93577 and CVE-2026-97229, an integer overflow in the size of a compiled pattern, in 19.4.1 and 19.4.2.
  • CVE-2026-110264, an overflow of internal identifiers in a pattern with many repeats, in 19.5.1.

CISA's own entry says it plainly in the notes: other products can potentially be affected by the same underlying Ruby and Onigmo issue. That is 1 sentence in a catalogue entry doing the work an advisory would normally do, and it points readers at Ruby's post rather than at any identifier of Ruby's own.

Ruby has not issued a CVE of its own

This is the part that should worry anyone running a scanner. Ruby says it has not requested CVE identifiers for these fixes, "at least for now", and that the team plans to discuss whether this class of issue should be treated as a vulnerability at all. Until that changes, the post suggests tracking GitLab's 4 numbers instead, which is advice nobody's tooling is built to follow.

So the identifiers that exist belong to the product that found the bug, not to the library that contains it. Every other Ruby application with the same exposure has nothing to match on, no advisory addressed to it, and no entry that will ever appear next to its own name.

We wrote about the opposite case 2 days ago, when the catalogue listed Brotli rather than a product. A library entry leaves the patching spread across everything that ships a copy. A product entry, as here, leaves everyone else without a number.

Who is actually exposed

Ruby's post is precise about this and worth quoting rather than paraphrasing: "Applications that only use regular expressions written by their own developers are not affected."

The bugs are reached when an application compiles a pattern from a string somebody else controls, which in practice means 3 calls, Regexp.new, Regexp.union and Regexp.compile, plus interpolating that input into a literal. GitLab's CI/CD configuration is exactly that shape, because the pattern comes from the repository.

Two defences people reach for do not work here. Ruby states that "Regexp.timeout does not protect against these bugs", which matters because that is the control added for the last generation of regular expression problems. And limiting pattern length is unreliable, because some of these can be triggered by short patterns.

What GitLab shipped, and when

The critical patch release on 12 October covered 19.4.2, 19.3.5 and 19.2.8, and the affected ranges are everything from 19.2 before 19.2.8, 19.3 before 19.3.5 and 19.4 before 19.4.2. The vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, which is how a flaw reaches 10.0.

It was reported by joaxcar through GitLab's HackerOne programme. GitLab also shipped 6 threat detections for self-managed instances to help customers find exploitation attempts, and says its own hosted platforms were already patched.

Then 17 days passed between that release and the catalogue listing, which is the window in which somebody used it.

What to do

  • Patch GitLab to 19.4.2, 19.3.5 or 19.2.8 or later. The federal deadline is 1 November, and the entry asks for forensic triage, so look before you upgrade if you are in scope.
  • Upgrade Ruby to 4.0.9, 3.4.12 or 3.3.13 anywhere you run it. GitLab patched the Ruby it ships, which does nothing for your other applications.
  • Audit for Regexp.new, Regexp.union, Regexp.compile and interpolation into patterns, anywhere the input is not yours. That list is the exposure.
  • Do not rely on Regexp.timeout or a length cap. The upstream post says neither helps.
  • If you scan dependencies, understand that these will appear under GitLab's identifiers or not at all.

What is not established

  • How it is being exploited, by whom, and against how many instances. CISA lists it and publishes nothing further.
  • Whether anything other than GitLab has been attacked through the same Onigmo bugs. Nobody has said, and there is no identifier to search for.
  • Whether Ruby will assign its own CVEs. The post says the team intends to discuss it.
  • How many Ruby applications compile attacker-controlled patterns. That is the real population and nobody has measured it.
  • What the 6 GitLab threat detections have found.