GitLab CVE-2026-97229: exploited CI/CD regex flaw, and why upgrading GitLab alone may not fix it

What changed

• 12 October: GitLab released 19.4.2, 19.3.5 and 19.2.8 for Community Edition (CE) and Enterprise Edition (EE). GitLab says GitLab.com was already running the patched version and all GitLab Dedicated tenants were patched before the release was published.
• 23 October: Ruby released 4.0.9, 3.4.12 and 3.3.13, which fix the underlying bugs in Onigmo, the regular-expression engine built into Ruby.
• 28 October: Alpine Linux published an account of attempted exploitation against its own GitLab instance.
• 29 October: CISA added CVE-2026-97229 to the KEV catalogue “based on evidence of active exploitation”.

GitLab describes CVE-2026-97229 as an integer overflow in the CI/CD regular-expression compiler. Its advisory says that, “under certain conditions”, 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. The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H.

What CISA’s KEV entry says

CISA’s required action is to “apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk … guidance and CISA’s ‘Forensics Triage Requirements'”, and to “discontinue use of the product if mitigations are unavailable”. The entry also notes that “other products can potentially be affected by the same underlying Ruby/Onigmo Integer Overflow issue”.

The due date and the triage requirement are obligations for US federal agencies. In CISA’s words, “BOD 26-04 applies only to FCEB agencies” (Federal Civilian Executive Branch), but CISA “encourages all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV Catalog vulnerabilities”. For everyone else, the useful signal is that CISA has evidence of exploitation and expects defenders to check for compromise, not just to patch.

Exploitation evidence

• Alpine Linux. Alpine says a newly registered account sent crafted CI configurations to its GitLab instance on 20 and 21 October, a week after GitLab’s fix, while the instance was still on 19.3.4. Worker processes crashed eight times. Alpine found no evidence that the attacker ran code, but says it cannot rule it out, so it treated the instance as compromised, rebuilt it from scratch, reset all passwords and replaced GitLab’s secret keys. Alpine says its aports repository, packages and 21 October releases were not tampered with.
• Rapid7. On 13 October Rapid7 reported reproducing code execution in a lab against an unpatched official GitLab 19.4.1 CE image; the same input did not execute against the patched 19.4.2 image. In Rapid7’s tested route, the attacker first needs to be able to commit a CI/CD configuration to a public project. Rapid7 notes that this precondition is removed on instances where new users can self-register and create projects. At the time of writing, Rapid7 said there was no confirmed in-the-wild exploitation; CISA’s KEV listing has since changed that.

We have not seen public attribution, victim counts or indicators of compromise beyond the detections GitLab has published and Alpine’s account.

Who is affected

• Self-managed GitLab on its own Ruby. Alpine upgraded to GitLab 19.3.6 on 22 October and was still vulnerable. Alpine explains that the fix “isn’t in GitLab’s own code but in a patch to Ruby, which GitLab applies only in its official packages”, and its image used standard Ruby. If you run GitLab from source or in your own container image, you also need Ruby 3.3.13, 3.4.12, 4.0.9 or later.
• Highest exposure. Internet-facing instances that allow open self-registration and let ordinary users create projects.
• Other Ruby applications. Ruby says these bugs are reached only when an application compiles a regular expression from a string an attacker controls, for example with Regexp.new, Regexp.union, Regexp.compile or by interpolating input into a regexp literal. Ruby also says Regexp.timeout does not protect against these bugs, and limiting pattern length does not reliably protect either.
• Not affected: GitLab.com and GitLab Dedicated, according to GitLab.

What to do now

1. Preserve evidence first. Before you upgrade or rebuild, copy off GitLab application, Workhorse and background-job logs and, for containers, the container filesystem. CISA’s forensic triage guidance notes that patching may destroy artefacts, and Alpine says some of its attack-day logs were lost with the old container.
2. Patch GitLab. Move self-managed GitLab to 19.2.8, 19.3.5, 19.4.2 or a later patch release. GitLab says this patch includes database migrations; single-node instances will have downtime, while multi-node instances can use zero-downtime upgrade procedures. Ruby’s advisory also lists a later related GitLab CVE, CVE-2026-110264, fixed in GitLab 19.5.1, so aim for the latest patch release for your series.
3. Check the Ruby that actually runs GitLab. For source installs and custom images, confirm it is Ruby 3.3.13, 3.4.12, 4.0.9 or later. The GitLab version number does not tell you this. Alpine also notes that its own alpinelinux/gitlab 19.3.6 image was only fixed in the build published on 27 October.
4. Reduce exposure while you patch. Rapid7 suggests restricting anonymous access to public projects and preventing untrusted users from creating or writing to public projects. Disabling open self-registration (or requiring admin approval) and keeping the instance behind a VPN or allow-list also help. These steps narrow the known delivery path; they do not fix the flaw.
5. Audit other Ruby applications that build regular expressions from user input, and update their Ruby too.

What to look for

GitLab has published six threat detections for self-managed customers:

• Onigmo native worker crash
• GraphQL CI lint hostile regexp
• CI regexp oversized non-ASCII path
• CI regexp guard rejection
• CI lint Workhorse worker crash
• CI lint scripted client error burst

Alongside those, review logs from at least 12 October for unexplained worker crashes and 502 errors around CI lint, newly registered accounts that create projects and push CI configuration, and unusual activity by the git system user, which Rapid7’s lab exploit ran commands as. Bear in mind Alpine’s warning that “a successful exploit would leave no crash and no trace in the web logs”. A clean log review lowers the risk; it does not prove the server was not compromised.

If you find signs of an attempt, treat it as a possible compromise. Alpine’s response is a reasonable model: preserve logs, rebuild from known-good sources, reset passwords and replace secret keys. Alpine lists CI/CD variables, runner tokens, 2FA secrets, webhook, integration and push mirror credentials, and private repositories among the data that a successful exploit could have exposed, so rotate those secrets and review recent commits, tags and pipeline definitions for tampering.

Why it matters for defenders

A self-managed GitLab server usually holds source code, CI/CD secrets and the keys to deployment pipelines, so code execution there is a supply-chain risk, not a single-host incident. The Alpine case also shows a gap that version-based scanning misses: a host can report a “fixed” GitLab version and still be exploitable because of the Ruby it runs on. Ruby has not requested its own CVE identifiers for these fixes and asks users to track them under GitLab’s CVEs, so scanners that check only Ruby may not flag them.

What we do not know yet

• CISA has not published the evidence behind the KEV listing, and we have seen no public attribution or victim count.
• Rapid7 says it does not yet know how the attack in the original, still-private report to GitLab avoids the repository write step.
• Alpine has not said how its attacker’s CI configurations reached GitLab, or whether new accounts could create public projects on its server.
• Whether GitLab will update its source-install guidance to require a fixed Ruby version.

Related reading: our earlier notes on self-managed GitLab file read (CVE-2026-85706) and the self-hosted GitLab AI Gateway trust boundary (CVE-2026-90970).

How PoCForge can help

If you want an independent view of how exposed your self-managed GitLab and CI/CD pipelines are, our application security testing can look at the web application and its APIs, and external infrastructure testing covers what the internet can reach, as part of our wider infrastructure testing. If you think an instance may already have been compromised, an assumed breach assessment can test what an attacker could reach from it. Get in touch and we can scope an assessment with you.

Sources

• GitLab, “GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8” (12 Oct 2026)
• CISA Known Exploited Vulnerabilities catalogue entry for CVE-2026-97229
• CISA Known Exploited Vulnerabilities catalogue feed (version 2026.10.29)
• CISA, “CISA Adds Two Known Exploited Vulnerabilities to Catalog” (29 Oct 2026)
• CISA, BOD 26-04 implementation guidance, forensic triage steps
• NVD, CVE-2026-97229
• Ruby, “Regexp compilation fixes related to GitLab’s CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264” (23 Oct 2026)
• Alpine Linux, “GitLab security incident: attempted exploitation of CVE-2026-97229” (28 Oct 2026)
• Rapid7, “CVE-2026-97229: Critical Unauthenticated Remote Code Execution in GitLab” (13 Oct 2026)
• The Hacker News, coverage of the Alpine Linux report

PoCForge publishes offensive-security research to explain attack paths and defensive controls. This article summarises public advisories and reporting only; it is not an exploit guide and does not describe a named client engagement.