The US Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-97229 to its Known Exploited Vulnerabilities (KEV) catalog on October 29, 2026. The flaw in GitLab Community Edition and Enterprise Edition carries the maximum CVSS score of 10.0: an unauthenticated attacker can execute code on the GitLab server through a specially crafted regular expression in a CI/CD configuration. GitLab shipped fixes on October 12. The case of Alpine Linux’s infrastructure shows, however, that upgrading GitLab alone is not enough in every setup.
If you run GitLab yourself, check not only the version number but also which Ruby version your installation actually uses. Here is what is known, who is affected and what administrators should do now.
Key Takeaways
- CVE-2026-97229 is an integer overflow in the regular expression compiler used for CI/CD configurations, rated CVSS 10.0. It allows remote code execution without authentication.
- Affected versions are GitLab CE/EE 19.2 before 19.2.8, 19.3 before 19.3.5 and 19.4 before 19.4.2. According to GitLab, GitLab.com and GitLab Dedicated are already patched.
- CISA has listed the flaw as actively exploited since October 29. US federal civilian agencies must act by November 1, and a forensic check is required.
- The underlying bug sits in Onigmo, Ruby’s regular expression engine. If you run GitLab on your own Ruby, you also need Ruby 3.3.13, 3.4.12 or 4.0.9.
- Alpine Linux reports an exploitation attempt on October 20 and 21. It found no evidence of success but rebuilt its instance from scratch as a precaution.
What is CVE-2026-97229?
According to the GitLab Critical Patch Release 19.4.2, 19.3.5 and 19.2.8, the issue is an “Integer Overflow issue in CI/CD Regular Expression Compiler”. GitLab describes the impact as follows: under certain conditions, an unauthenticated user could execute arbitrary code on the GitLab server via a specially crafted regular expression in a CI/CD configuration, due to insufficient regular expression validation. The CVSS vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, meaning a network attack with low complexity that requires no privileges and no user interaction.
Security researcher Johan Carlsson (joaxcar) reported the flaw through GitLab’s bug bounty program on HackerOne. The October 12 patch release contains 24 security fixes in total, and CVE-2026-97229 is the only one rated “Critical”. GitLab also published six detections for self-managed instances, including crashes of the native Onigmo worker, rejected CI regex checks and bursts of errors on the CI lint endpoint.
The core of the problem is in Ruby
GitLab compiles regular expressions that users supply, for example in CI configuration, with Regexp.new. As the Ruby team explains in its notice from October 23, specially crafted patterns could corrupt memory while Ruby compiles them, and this could be turned into remote code execution on GitLab servers. CVE-2026-97229 traces back to an integer overflow in the size of a compiled pattern.
Four GitLab CVEs are tied to Onigmo bugs: CVE-2026-89078 (double free in the parser, fixed in GitLab 19.4.1), CVE-2026-93577 (integer overflow, 19.4.1), CVE-2026-97229 (19.4.2) and CVE-2026-110264 (overflow of internal IDs in patterns with many repeats, 19.5.1). GitLab fixed them in its official packages and container images by patching the Ruby it ships. Upstream Ruby has shipped the fixes since October 23 in versions 4.0.9, 3.4.12 and 3.3.13.
This matters for every Ruby developer. According to the Ruby team, only applications that compile a regular expression from a string an attacker controls are affected, for example via Regexp.new, Regexp.union, Regexp.compile or interpolation such as /#{input}/. Applications that only use patterns written by their own developers are not affected. Regexp.timeout explicitly does not protect against these bugs, and limiting pattern length is not reliable either, because some of them can be triggered by short patterns. The Ruby team has not requested CVE identifiers of its own so far and points scanners to the GitLab CVEs.
Why CISA is raising the alarm now
CISA added CVE-2026-97229 to the KEV catalog on October 29 together with a Cisco flaw (CVE-2026-76418), “based on evidence of active exploitation”. Under directive BOD 26-04, federal civilian agencies have until November 1, 2026. CISA also requires forensic triage, meaning agencies must check whether a system was compromised before the patch was applied. Whether the flaw is used in ransomware campaigns is listed as unknown. One note in the catalog entry stands out: other products could potentially be affected by the same underlying Ruby/Onigmo issue.
The Alpine Linux case: patched, yet still exposed
How real the threat is becomes clear from a detailed incident report by Alpine Linux published on October 28. On October 20 and 21, a newly registered account sent crafted CI configurations to the project’s GitLab instance. It was still running 19.3.4, because on October 13 the team had mistakenly upgraded to 19.3.4 instead of 19.3.5, which contained the fix. The attacks crashed GitLab worker processes eight times, and in four of those crashes the attacker got partway through the exploit before failing at the next step, according to Alpine. The attacker also downloaded the project’s GitLab container image, which Alpine reads as a sign that the exploit was being tuned to its exact build.
Upgrading to GitLab 19.3.6 on October 22 did not close the hole. Alpine’s own image used standard Ruby, but the fix only exists in the patched Ruby of GitLab’s official packages. The team only noticed on October 26 that the instance was still vulnerable. Alpine found no evidence that code was executed, but cannot rule it out, because a successful exploit would leave no crash and no trace in the web logs, and some logs are gone. The project therefore rebuilt the instance, reset all passwords and replaced GitLab’s secret keys. According to Alpine, packages, signing keys and the October 21 releases were verified against outside records and were not tampered with.
CVE-2026-97229: what GitLab admins should do now
- Check and upgrade: Install at least 19.4.2, 19.3.5 or 19.2.8, ideally the latest release of your branch. The release notes mention database migrations, so single-node instances should expect downtime.
- Verify the Ruby version: If you run GitLab from source or with your own container image, you also need Ruby 3.3.13, 3.4.12 or 4.0.9 or later. This is exactly what caught Alpine out.
- Look for traces: The six detections published by GitLab help to find exploitation attempts. Unusual worker crashes, CI lint errors and odd pipeline configurations from new accounts are warning signs.
- Treat suspicion as compromise: In our view, Alpine’s list of data that could have been exposed is a useful checklist: CI/CD variables, runner tokens, webhook and mirror credentials, and 2FA secrets. When in doubt, rotate them.
- Reduce the attack surface: In the Alpine case, the attacker used a newly registered account. Restricting open sign-ups does not replace patching, but it reduces the pool of potential attackers.
Beyond GitLab, it is worth checking your own code: any Ruby application that compiles patterns from user input should move to a fixed Ruby version. The pattern resembles other supply chain problems from recent weeks, such as the LiteLLM supply chain attack or the npm dependency confusion wave with 14 packages: the weakness is not in your own code but in a component underneath it. The Laravel TokenGuard vulnerability recently showed how quickly such flaws in web frameworks become critical.
Assessment
CVE-2026-97229 is not a new finding, but its addition to the KEV catalog changes the picture. About a week passed between the October 12 patch and the attempts against Alpine, and the incident exposes a gap many operators may overlook: in GitLab, the fix is tied to the bundled Ruby version. If you use the official Omnibus packages or images and have upgraded, you are protected based on what is known today. If you run your own builds, check today which Ruby is actually running. Code hosting servers are attractive targets, because source code, CI secrets and deployment credentials sit in one place.
