CISA added CVE-2026-97229 to the Known Exploited Vulnerabilities catalog on October 29, 2026, with a due date of November 1 and the forensic-triage flag set. Three days. It is a CVSS 10.0 unauthenticated remote code execution in GitLab CE/EE, fixed in GitLab's October 12 critical patch release.
That is not the version range you need. CVE-2026-97229 is one of four CVEs GitLab opened against the same regular-expression engine in four weeks, and it has the shortest affected-version list of the four. The exploitation claim is CISA's alone — GitLab's advisory makes no in-the-wild statement, it ships six threat detections.
The cluster, with GitLab's own version strings
| Release date | CVE | CVSS | Auth | Impacted versions |
|---|---|---|---|---|
| Sept 23 | CVE-2026-89078 (double free) | 9.9 | authenticated | from 19.2 before 19.2.7, 19.3 before 19.3.3, 19.4 before 19.4.1 |
| Sept 23 | CVE-2026-93577 (integer overflow) | 9.9 | authenticated | from 19.2 before 19.2.7, 19.3 before 19.3.3, 19.4 before 19.4.1 |
| Oct 12 | CVE-2026-97229 (in KEV) | 10.0 | unauthenticated | from 19.2 before 19.2.8, 19.3 before 19.3.5, 19.4 before 19.4.2 |
| Oct 21 | CVE-2026-110264 | 10.0 | unauthenticated | all versions from 7.0 before 18.11.13, 19.0 before 19.0.10, 19.1 before 19.1.9, 19.2 before 19.2.9, 19.3 before 19.3.6, 19.4 before 19.4.3, 19.5 before 19.5.1 |
The bottom row is the problem. CVE-2026-110264 is the same severity, the same unauthenticated code execution and the same regex compiler as the KEV entry — and it is not in the catalog. As of KEV version 2026.11.03, released November 3, only CVE-2026-97229 of the four is listed, so no federal deadline attaches to CVE-2026-110264.
An operator running GitLab 18.11 who triages against the KEV entry reads "from 19.2" and closes the ticket. GitLab backported a fix to 18.11.13 specifically because that operator is affected by the worse of the two.
Four CVEs, three Ruby bugs
The ranges disagree because these are not four GitLab defects. GitLab compiles user-supplied patterns — CI configuration, among other places — with Regexp.new, and the memory corruption is in Ruby's Onigmo engine. Ruby's own write-up maps them: change #13332 fixes CVE-2026-89078; change #19020 fixes CVE-2026-93577 and CVE-2026-97229; change #16801 fixes CVE-2026-110264. Three bugs, four identifiers.
Read the release columns in that table and the trap repeats one layer down. Ruby 4.0.8 carries #19020 — the fix behind the KEV entry — but not #16801. A fleet standardized on 4.0.8 is half-patched by Ruby's own accounting. Only 4.0.9, 3.4.12 and 3.3.13 carry all three.
GitLab says this explicitly in the October 21 release and it is the sentence most likely to be skipped: if your installation uses its own Ruby runtime rather than the bundled one, "upgrading GitLab is not sufficient: you must also upgrade Ruby." The fix for CVE-2026-110264 is a Ruby patch, shipped only in GitLab's official Linux packages and container images.
The practice: build the floor from the cluster, not the catalog entry
When a KEV entry names one CVE out of a vendor cluster touching the same component, the fixed version you need is the newest release in that cluster, not the one the catalog links. Here that is 19.4.3 / 19.3.6 / 19.2.9 / 19.1.9 / 19.0.10 / 18.11.13 — the October 21 line. Reaching 19.2.8 closes the November 1 deadline and leaves a 10.0 open, the same shape as the JFrog release whose July fixed version sat inside August's affected range.
The cost is small and real: you read three advisories instead of one, and KEV closure is measured against the listed CVE, so the extra work is invisible to the audit — which is why it gets skipped. The expensive case is the self-compiled install, where the Ruby bump means a rebuild and recompiled native extensions: budget a maintenance window, not a patch window. The inverse failure — treating the catalog as the thing that authorizes the work — is why KEV membership is not a patch trigger.
Then there is everything else you run on Ruby. Ruby declined to assign CVE identifiers for these fixes: "We have not requested CVE identifiers in Ruby for these fixes, at least for now," and it directs scanner users to GitLab's identifiers instead. So any application that compiles an attacker-controlled pattern — Regexp.new, Regexp.union, Regexp.compile, or interpolating input into a literal — is in the position GitLab was in, with nothing for a dependency scanner to match on. Two mitigations that sound reasonable do not work, in Ruby's words: Regexp.timeout does not protect against these bugs, and limiting pattern length does not reliably protect either, because some are triggered by short patterns. If you cannot upgrade the runtime, stop compiling patterns from untrusted input.
How to check this week
sudo gitlab-rake gitlab:env:info # GitLab version AND the Ruby it is using
ruby -v # on every other Ruby service you run
- Compare the GitLab version against 19.4.3 / 19.3.6 / 19.2.9 / 19.1.9 / 19.0.10 / 18.11.13, not against 19.2.8.
- Confirm whether that instance uses GitLab's bundled Ruby or a runtime you build. If you build it, it must be 4.0.9, 3.4.12 or 3.3.13 or later.
- Grep your own repositories for
Regexp.new,Regexp.unionandRegexp.compilewith a non-literal argument, and for interpolation into regexp literals. - Check that GitLab's six threat detections for this path fire into something you read. This is GitLab's second KEV entry in seven weeks — the September 11 one was a file-read bug where upgrading did not rotate the secrets GitLab was holding.
North InfoSec runs AI-assisted penetration testing and security assessments, including version-range and patch-verification work of the kind described above. northinfosec.com