CVE-2026-97229: GitLab CI/CD regex integer overflow enables unauthenticated remote code execution — KEV-listed with a November 1 deadline

CoeLab Real-World Impact: 95/100 — Urgent. Editorial score v1.0. Evidence checked 2026-10-31T09:10:25.059421+00:00. CVSS and EPSS are separate measures, not this editorial score.

Rating breakdown: exploitation: 30, reachability: 25, consequences: 25, operational relevance: 15.

Who is affected

This flaw affects self-managed GitLab Community Edition and Enterprise Edition in the ranges the vendor documents: all versions from 19.2 before 19.2.8, all versions from 19.3 before 19.3.5, and all versions from 19.4 before 19.4.2. GitLab's advisory states the issue applies to every deployment type (Omnibus, source, Helm chart, and similar) unless a specific type is named. Fixes landed together in the October 12, 2026 patch release 19.4.2/19.3.5/19.2.8.

Two groups of self-managed operators should pay particular attention. The first is anyone running an affected release that is reachable on a network where strangers can reach it — including the many organizations, homelabs, and shared-infrastructure operators who run GitLab CE for internal use but expose the web interface or CI endpoints more broadly than necessary. The second is operators who do not patch GitLab frequently: this bug's root cause sits in the Ruby interpreter GitLab ships, which means the practical remediation depends on the patched GitLab builds rather than any configuration change.

GitLab.com (gitlab.com) and GitLab Dedicated tenants were already patched — GitLab.com runs the fixed version and Dedicated received an internal patch before the public release. If you only consume these hosted offerings, the vendor has addressed the flaw on your behalf, and this article is chiefly context for your vulnerability-management paperwork, not a fire drill.

Real-world impact and exploitation evidence

The vulnerability is an integer overflow in the regular-expression compiler (Onigmo) reached through GitLab's CI/CD configuration validation. GitLab's own description is blunt: in certain conditions an unauthenticated user can execute arbitrary code on the GitLab server by submitting a crafted regular expression in a CI/CD configuration. Arbitrary code execution on a source-control and CI server usually means the repository contents, CI secrets and credentials, and deployment credentials inside runners are all within reach of the attacker. That is a supply-chain position, not just a compromised host.

The published CVSS 3.1 vector — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — scores 10.0, Critical. The vector is consistent with the vendor narrative: network attack vector, low attack complexity, no privileges required, no user interaction, changed scope, and high impact across all three dimensions. Exploit-prerequisite nuance is not encoded in CVSS, so read the attack-prerequisites section below for what actually has to be true in your environment.

On exploitation evidence: CISA added CVE-2026-97229 to the Known Exploited Vulnerabilities catalog on October 29, 2026, with a required-action due date of November 1, 2026, and flagged it for forensic triage. Inclusion in KEV is the U.S. government's confirmation that exploitation is occurring or credible at scale — it is evidence of live exploitation pressure, though the catalog does not attribute campaigns. GitLab has also released six specific threat-detection rules for self-managed operators looking for exploitation attempts in their logs (covering Onigmo worker crashes and hostile-regex CI lint patterns), which is a strong indication that attempt activity is being observed in the wild. Two HackerOne reports tied to this CVE carry exploit tags, and a Metasploit Framework pull request referencing the CVE exists publicly. EPSS currently reads about 0.27 (98th percentile), meaning the modeling community also rates exploitation probability well above typical. We saw no vendor statement tying this bug to ransomware specifically; CISA lists ransomware campaign use as Unknown.

Timeline is worth untangling because several dates circulate: the GitLab patch release shipped October 12, 2026 (the CVE list record is dated October 13); the Ruby project published upstream fixes on October 23; CISA's KEV listing came October 29. The KEV entry is current news about an already-patched flaw. If your patching program reacted to the October 12 advisory, this listing changes your prioritization, not your inventory of affected systems.

Attack prerequisites

The attacker must be able to send a crafted regular expression to a GitLab component that compiles it, and the GitLab process must be running a Ruby interpreter with the unpatched Onigmo code. GitLab compiles user-supplied patterns — the canonical path is the CI/CD configuration linting/validation flow that turns `.gitlab-ci.yml`-style inputs into real regex objects via `Regexp.new`-equivalent compilation. No authentication was required in the vendor's description, and CVSS scores the vector as network-reachable with no privileges.

What is not required: valid credentials, an existing project, or a runner. What is required: network reachability to an affected GitLab instance's relevant endpoints. An instance that only accepts connections from a trusted management network, VPN, or localhost is dramatically harder to attack than one exposed to the internet, even though the code-level vulnerability is identical. Exposure — not exposure plus sophistication — is the practical gate here.

It is also worth stating the scope boundary precisely, because the underlying bug affects more than GitLab. The Ruby project's advisory explains the bug is reachable only when an application compiles a regular expression from attacker-controlled input (for example, passing untrusted strings to `Regexp.new`, `Regexp.union`, `Regexp.compile`, or interpolating them into a regex literal). Applications that only execute regexes written by their own developers are not affected by this class of bug. GitLab assigns CVEs because it meets exactly that condition at scale; other Ruby applications doing the same should not read 'CVE is GitLab-specific' as reassurance. `Regexp.timeout` does not protect against these bugs, and pattern-length limits are unreliable mitigations because some triggers are short — mitigation has to be the upgraded interpreter, not input screening.

Actions and fixes

Upgrade self-managed GitLab to one of the fixed patch releases immediately: 19.2.8, 19.3.5, or 19.4.2 — or any newer release in the corresponding series. GitLab's advisory recommends all affected installations upgrade as soon as possible, and under CISA's BOD 26-04 process federal-facing organizations must remediate by November 1, 2026 (or discontinue use where mitigations are unavailable). Treat that date as a reasonable ceiling for private-sector urgency too, not a floor.

The fix is delivered through GitLab's patched builds because GitLab vendors its own Ruby. If you run GitLab in a container or an Omnibus package, updating the GitLab version is the whole job; do not attempt to patch Ruby inside a supported GitLab package independently. Any Ruby-based service your organization runs elsewhere that compiles regexes from untrusted input should independently move to Ruby 4.0.9, 3.4.12, 3.3.13, or later, per the Ruby project's advisory — those releases fold in the fixes for this bug and the sibling CVEs.

Until patching completes, the only meaningful containment is exposure control: restrict what can reach the vulnerable endpoints. GitLab's advisory does not offer a configuration toggle that disables this compilation path, so there is no vendor-endorsed parameter to flip instead of upgrading. Internet-exposed instances should get patched fastest. Organizations on GitLab Dedicated or gitlab.com can verify they are on vendor-managed infrastructure and stand down.

After patching, use GitLab's published threat-detection rules to check whether anyone attempted exploitation before the fix: look for Onigmo native worker crashes and the hostile-regex CI lint patterns GitLab documents. If your logs show those signatures against a pre-patch instance, treat it as a possible compromise — this vulnerability yields arbitrary code execution, so credential and secret rotation on that instance is the prudent follow-up, and CISA's forensic-triage flag exists for exactly this scenario.

Uncertainty and what could change

Several details remain open rather than settled. GitLab's public issue tracker releases the underlying vulnerability issue 90 days after the patch, so granular root-cause detail from the vendor is currently limited to the summary above; the strongest public technical documentation today is the Ruby project's upstream advisory. We have not independently verified in-lab that the HackerOne PoCs or the Metasploit pull request produce working end-to-end exploitation against a specific target version, and we make no claim about how reliably the memory-corruption primitive escalates to stable code execution — 'could have allowed arbitrary code execution under certain conditions' is the vendor's phrasing and we carry that hedge forward.

Observed exploitation is inferred from CISA's KEV listing plus GitLab's own detection guidance; neither source currently names threat actors, victim counts, or ransomware association. If CISA later updates the entry with campaign attribution, or GitLab publishes incident data, the picture could sharpen quickly — in either direction. EPSS values move daily, so today's 0.27 figure is a snapshot at evidence time, not a constant.

Finally, note that CVE-2026-97229 is one of four sibling CVEs in the same regex-compilation bug class (CVE-2026-89078, CVE-2026-93577, CVE-2026-110264, and this one) fixed across the 19.4.1/19.4.2/19.5.1 patch lines and Ruby 3.3.13/3.4.12/4.0.9. If you are remediating this CVE, ensure your upgrade target actually covers all four, since staying on a release that fixed only one of them leaves a similar attack surface behind.

Sources and evidence date

This analysis is grounded in four primary or authoritative sources, all reviewed on October 31, 2026: GitLab's patch release advisory for 19.4.2/19.3.5/19.2.8 (vendor statement of affected and fixed versions, CVSS 10.0 vector, deployment guidance, and exploitation-attempt detections); the Ruby project's October 23, 2026 advisory (root cause, affected application patterns, mitigation limits including the ineffectiveness of `Regexp.timeout`, and fixed Ruby releases); the CISA Known Exploited Vulnerabilities catalog as reflected in the official CVE List enrichment (KEV addition October 29, 2026, due date November 1, 2026); and the CVE Program record for CVE-2026-97229. The underlying CVE record's data was observed at evidence time October 31, 2026; EPSS is from FIRST.org as of October 30, 2026.

Primary-source links

https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/

https://www.ruby-lang.org/en/news/2026/10/23/regexp-fixes-for-gitlab-cves/

https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-97229

https://www.cve.org/CVERecord?id=CVE-2026-97229

AI-assisted research and drafting, with a separate model editorial review. CoeLab ratings are editorial judgments, not a substitute for checking your own versions and vendor advisories. Methodology: https://thecoelab.com/blog/security/methodology