CVE-2026-97229 is a remote code execution bug in self-managed GitLab Community and Enterprise Edition. GitLab’s 19.4.2 patch release says it “could have allowed an unauthenticated user to execute arbitrary code on the GitLab server via a specially crafted regular expression in a CI/CD configuration, due to insufficient regular expression validation.” GitLab scores it CVSS 3.1 10.0. CISA added it to the Known Exploited Vulnerabilities catalog on October 29, 2026, with a due date of November 1.

If you run self-managed GitLab, do two things today: upgrade to the October 21 patch release for your branch (not just the October 12 one), and check for signs that someone got there first.

What is affected and what fixes it

CVE-2026-97229 is one of four GitLab CVEs that trace back to bugs in Onigmo, the regular expression engine inside Ruby. GitLab fixed them in three patch releases between September and October. Ruby’s own advisory of October 23 ties them together.

Only CVE-2026-97229 is in KEV today. CISA’s SSVC entries in the CVE records list Exploitation as “active” for CVE-2026-97229 and “none” for the other three, as of the dates CISA recorded them. CVE-2026-110264 is also unauthenticated and rated 10.0, and its range reaches back to GitLab 7.0, so treat it with the same urgency.

Upgrade target: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13, or anything later on the same branch. If you are on a branch older than 18.11, there is no backport; move to a supported branch. GitLab’s 19.5.1 release post lists no workaround, only “upgrade to the latest version as soon as possible.”

GitLab.com and GitLab Dedicated are already patched, according to both release posts. This is a self-managed problem.

Check a version quickly

The Version API returns the running version (GET /api/v4/version with a token). The script below compares a version string against the affected ranges in the four CVE records. We ran it with Python 3.13; the output shown is real.

#!/usr/bin/env python3
"""Check a GitLab version against the four Onigmo regex CVEs.
Fixed versions come from each CVE record's 'affected' ranges (read 2026-10-30)."""
import re, sys

FIXED = {  # CVE -> {(major, minor): first fixed patch}
    "CVE-2026-89078":  {(19, 2): 7, (19, 3): 3, (19, 4): 1},
    "CVE-2026-93577":  {(19, 2): 7, (19, 3): 3, (19, 4): 1},
    "CVE-2026-97229":  {(19, 2): 8, (19, 3): 5, (19, 4): 2},
    "CVE-2026-110264": {(18, 11): 13, (19, 0): 10, (19, 1): 9, (19, 2): 9,
                        (19, 3): 6, (19, 4): 3, (19, 5): 1},
}
OLD_RANGE_START = {"CVE-2026-110264": (7, 0)}  # affected from 7.0, no fix before 18.11

def check(ver):
    major, minor, patch = map(int, re.match(r"(\d+)\.(\d+)\.(\d+)", ver).groups())
    branch, out = (major, minor), {}
    for cve, fixes in FIXED.items():
        if branch in fixes:
            out[cve] = "FIXED" if patch >= fixes[branch] else f"VULNERABLE (fixed in {major}.{minor}.{fixes[branch]})"
        elif branch > max(fixes):
            out[cve] = "FIXED (newer branch)"
        elif cve in OLD_RANGE_START and branch >= OLD_RANGE_START[cve]:
            out[cve] = "VULNERABLE (no fix on this branch)"
        else:
            out[cve] = "not in affected range"
    return out

for v in sys.argv[1:]:
    print(v)
    for cve, status in check(v).items():
        print(f"  {cve:16} {status}")

$ python3 check_gitlab_regex_cves.py 19.4.2-ee 18.9.4
19.4.2-ee
  CVE-2026-89078   FIXED
  CVE-2026-93577   FIXED
  CVE-2026-97229   FIXED
  CVE-2026-110264  VULNERABLE (fixed in 19.4.3)
18.9.4
  CVE-2026-89078   not in affected range
  CVE-2026-93577   not in affected range
  CVE-2026-97229   not in affected range
  CVE-2026-110264  VULNERABLE (no fix on this branch)

The first result is the trap: an instance patched promptly on October 12 for the CVE that is now in KEV is still exposed to the sibling bug.

How the bug works, as far as the sources say

GitLab lets users supply regular expressions in places such as CI/CD configuration and compiles them with Ruby. Ruby’s advisory explains: “GitLab compiles regular expressions supplied by its users, such as patterns in CI configuration, with Regexp.new. GitLab found that specially crafted patterns could corrupt memory while Ruby compiles them, and that this could be turned into remote code execution on GitLab servers.”

The Ruby change behind CVE-2026-97229 (and CVE-2026-93577) is described as an “Integer overflow in the size of a compiled pattern”, fixed in ruby/ruby#19020. GitLab patched the Ruby it ships rather than waiting for a Ruby release.

GitLab says the bug is reachable by an unauthenticated user “under certain conditions” and does not spell those conditions out. The names of GitLab’s own detections (below) refer to the CI Lint feature and its GraphQL endpoint, which suggests where to look first, but that is our reading of the detection names, not a statement from GitLab. No public write-up of the exploitation we could find gives more detail; treat any blog that claims a precise attack path without citing GitLab or the reporter with caution.

Hunt: GitLab’s detections

The 19.4.2 release post lists six detections for self-managed instances, each linked to a write-up in GitLab’s gitlab-security-oss/tldr repository under Detections/platforms/GitLab/Vulnerability Detections/:

The 19.5.1 post adds two for CVE-2026-110264: “Onigmo native worker crash” and “Org mode render error burst”.

We have not reproduced these detections; use GitLab’s files for the exact log sources and queries. Practical order of work:

1. Look back before the patch date. Run the detections over logs as far back as your retention allows, up to the moment you upgraded. Worker crashes in the regex engine are not normal background noise.
2. Assume the GitLab host is a credential store. A GitLab server holds CI/CD variables, runner registration tokens, deploy keys, and access tokens. If you find hits, or you cannot rule exploitation out, rotate those secrets and review recent pipeline and runner activity. Our guide to detecting and rotating leaked API keys covers the rotation order.
3. Check for persistence. Look for new admin users, personal access tokens you did not create, new SSH keys on admin accounts, and unexpected files or processes on the host.

KEV marks this entry forensicTriage: Yes. Under CISA’s BOD 26-04 that means federal agencies must collect forensic data, not just patch; our BOD 26-04 explainer covers what that involves and what private teams can borrow.

If you run Ruby but not GitLab

Ruby released 4.0.9, 3.4.12 and 3.3.13 with fixes for all the underlying Onigmo bugs. Ruby’s advisory is precise about who is affected:

These bugs are reached only when an application compiles a regular expression from a string that an attacker controls, for example by passing it to Regexp.new, Regexp.union or Regexp.compile, or by interpolating it into a regexp literal such as /#{input}/. Applications that only use regular expressions written by their own developers are not affected.

Two points in that advisory matter for anyone building search filters, routing rules or admin “match by pattern” features:

• “Regexp.timeout does not protect against these bugs.” Timeouts address ReDoS, not memory corruption during compilation.
• “Limiting the length of patterns does not reliably protect against them either, because some of them can be triggered by short patterns.”

Ruby has not requested its own CVE IDs, so scanners may not flag your Ruby runtime. A quick way to find candidates in a codebase (illustrative, not exhaustive):

grep -rnE 'Regexp\.(new|union|compile)\(|/[^/]*#\{' --include='*.rb' app lib

Review each hit for whether the pattern can come from a user. If it can, upgrade Ruby, and consider whether users need regexes at all: plain substring or glob matching is a much smaller attack surface.

Limits of this article

• GitLab has not published the exact preconditions for unauthenticated exploitation, and we have not tested an exploit. The CI Lint connection above is inferred from detection names.
• KEV listing tells you exploitation has happened, not how widely. We found no primary source for a count of exposed or compromised instances.
• Version data comes from the CVE records as updated on 2026-10-30. If GitLab revises them, the records win over this page.

For how to weigh a KEV entry against CVSS and EPSS in your own queue, see CVSS vs EPSS vs KEV, and for reading the SSVC values quoted above, our Vulnrichment guide.

Sources and verification