GitLab CI/CD regex RCE now exploited (CVE-2026-97229)

CVE-2026-97229CVE-2026-93577CVE-2026-110264

CISA has added CVE-2026-97229, a CVSS 10.0 code execution flaw in GitLab CE/EE, to its Known Exploited Vulnerabilities (KEV) catalog. Any self-managed instance that was unpatched should be treated as a possible exposure of the machine credentials it stores, not just as a missed update.

What happened

GitLab fixed the flaw on October 12, 2026. The bug is an integer overflow in the CI/CD regular expression compiler. A malicious pattern placed in CI/CD configuration can give an attacker with no credentials code execution on the GitLab server, though GitLab qualifies this with "certain conditions."

  • Affected: 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2.
  • Not requiring action: GitLab says GitLab.com runs the patched version and Dedicated tenants were patched before the release.
  • Exploitation: CISA added the CVE to KEV on October 29, with a federal due date of November 1 and forensic triage required. Known ransomware use is listed as unknown. BleepingComputer reports that GitLab detected exploitation attempts and released threat detections for self-managed customers. GitLab's release notes publish those detections but do not themselves say attacks have occurred.
  • Exposure: BleepingComputer cites Shadowserver tracking nearly 2,800 internet-exposed GitLab Community Edition instances. Shadowserver does not say how many are patched.

The sources we read give no exploitation start date, IP addresses or file hashes, so the 17 days between patch and KEV listing say little about when attacks began.

Why it matters

GitLab's detection guidance explains that this flaw bypasses input checks added in 19.4.1 for an earlier bug, CVE-2026-93577. Placing Onigmo comment syntax inside a counted repeat's number hides the value from GitLab's bound scanner. UTF-8 recompilation then happens once the size check is already done. The guidance is explicit that 19.4.1 is not sufficient.

The identity problem is what the server holds. GitLab's guidance handles suspected code execution as a compromise, which means replacing four sets of credentials: the secrets in gitlab-secrets.json, CI/CD variables, runner tokens and access tokens. Those are mostly non-human credentials, and in our view they often reach well past GitLab, into cloud accounts, registries and production deploy paths. That makes a compromised server a supply chain problem as well as a host incident.

The root cause also reaches beyond GitLab. Ruby released 4.0.9, 3.4.12 and 3.3.13 to fix the underlying Onigmo bugs, and CISA's KEV entry warns that other products may be affected. Ruby limits the impact to applications that compile regular expressions from attacker-controlled strings, and it rules out Regexp.timeout as a defense. Ruby has not requested its own CVE IDs for now, and it advises scanner tracking under GitLab's identifiers.

What to check in your environment

  • Inventory and patch. List every self-managed instance and its exact version. The 19.4.2 notes warn that single-node instances will have downtime for migrations, while multi-node instances can use zero-downtime procedures.
  • Aim above the minimum. A related flaw, CVE-2026-110264, has later fixes: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13, per GitLab's detection guidance. Target those builds or newer.
  • Run GitLab's six detections. The rules we read are Sigma format. They use graphql_json.log, application_json.log, api_json.log, production_json.log and the Workhorse log, so confirm you collect them.
  • Check for crashes. Review puma_stderr.log and the Sidekiq log for [BUG] reports with Onigmo frames. GitLab warns that a successful exploit may not crash the worker, so no hits does not clear the instance.
  • Hunt for silent success. On the host, GitLab's guidance points to odd outbound traffic, processes spawned by Puma or Sidekiq that you cannot explain, /tmp files owned by git, and edits to crontabs or SSH keys. Also look for recent commits adding long file paths with non-ASCII characters.
  • Rotate if you find evidence. Start with GitLab's list above. Our addition: include deploy keys and OAuth application secrets, then review cloud and registry logs for use of those credentials after the suspected compromise.
  • Tighten account creation. GitLab's guidance recommends restricting account and personal access token creation.
  • Check other Ruby applications. Find code that passes untrusted input to Regexp.new, Regexp.union, Regexp.compile or an interpolated literal, and upgrade Ruby. Federal agencies should note that today is the KEV due date.

References

Original source: GitLab patch release notes