GitLab’s CI regex flaw entered CISA’s exploited-vulnerabilities catalog on October 29 as CVE-2026-97229. The flaw can let an unauthenticated attacker run code on a vulnerable GitLab Community Edition or Enterprise Edition server by supplying a crafted regular expression in CI/CD configuration. CISA set November 1 as the action date and marked forensic triage as required. For teams running self-managed GitLab, a patch that was already available in October now belongs in exploited-flaw response.

GitLab released the fixes on October 12. The company says its hosted GitLab.com service already runs a patched version and GitLab Dedicated tenants received an internal patch before that release. For your self-managed servers, collect the running releases and investigate activity against the CI input. Our earlier coverage of the CI regex patch described the flaw when GitLab published the fix; CISA’s later listing changes the response priority.

The CI pattern reaches Onigmo

GitLab accepts regular-expression patterns in CI configuration. The Ruby project’s account explains that GitLab compiles user-supplied patterns with Ruby’s regular-expression engine, Onigmo. Specially crafted patterns can corrupt memory during compilation. GitLab says the insufficient validation could, under certain conditions, lead to arbitrary code execution on the GitLab server without an authenticated user. Johan Carlsson, identified as joaxcar in GitLab’s bug-bounty acknowledgement, reported the integer-overflow issue.

GitLab parses the CI setting on its server; the vulnerable compiler does not need a pipeline job to run. Check the GitLab server even when ordinary CI jobs appear healthy. The GitLab-assigned CVE record gives the issue a 10.0 CVSS 3.1 base score and identifies the vulnerable branches. CISA’s catalog inclusion establishes exploitation in the wild; investigate affected servers for earlier intrusion while upgrading them.

Fixed GitLab and Ruby releases

For GitLab CE and EE, the affected ranges are 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2. GitLab recommends upgrading affected self-managed installations promptly; its patch release covers other security fixes too. Record the installed version on each self-managed server and move it to a current, supported patched release. After the upgrade, check the GitLab release running on each server.

Ruby addressed the underlying Onigmo integer overflow in the size of a compiled pattern in 4.0.8, 3.4.12, and 3.3.13; the Ruby maintainer notice recommends 4.0.9, 3.4.12, or 3.3.13 or later to cover the related regexp fixes. GitLab patched the Ruby it ships in its own releases. For separate Ruby applications, inventory paths that compile attacker-controlled patterns through Regexp.new, Regexp.union, or Regexp.compile, and upgrade the Ruby interpreter on those systems. Ruby puts the limit plainly: “Regexp.timeout does not protect against these bugs.” A pattern-length cap is unreliable too; short patterns can trigger some of the related bugs. Applications compiling only developer-authored regular expressions have a different exposure from applications compiling untrusted strings.

Attempts at the CI input

GitLab lists six threat detections for self-managed customers in its patch advisory. Their published names identify the surfaces to prioritize when reviewing security detections and correlated application logs:

  • Onigmo native worker crash
  • Graphql cilint hostile regexp
  • ci regexp oversized non ascii path
  • ci regexp guard rejection
  • ci lint workhorse worker crash
  • ci lint scripted client error burst

Preserve CI Lint and GraphQL request logs, Workhorse and application error logs, and worker-crash records from the period before the patch. Match the detection names to the telemetry available in your GitLab deployment, then correlate unusual CI configuration submissions, rejected patterns, error bursts or crashes with the same times and clients. These are places to start an investigation, not a clean-server certificate: CISA’s forensic-triage flag calls for looking beyond a detection match when a vulnerable server was reachable.

Upgrade and triage the server

First, inventory self-managed GitLab CE and EE servers and their installed versions. Upgrade affected 19.2, 19.3, or 19.4 systems to the fixed release for that branch or a current supported patched release, then confirm the running version on each server. For servers exposed while vulnerable, retain CI Lint, GraphQL, Workhorse, application and worker-crash evidence and investigate suspicious activity under your incident-response process. Assess each asset’s internet exposure as CISA instructs; constrain access to the GitLab service where your workflow permits while patching.

Check separate Ruby services that compile untrusted patterns, and upgrade their interpreters to the Ruby project’s recommended releases. A patched release removes this CI input flaw from the running GitLab build; log and host triage address activity during the vulnerable period. Take both results to the incident owner before returning an exposed server to routine maintenance.