GitLab CVE-2026-97229: CVSS 10 CI Regex RCE Now Exploited

What to do

1. Check the exact GitLab version on every self-managed instance: sudo gitlab-rake gitlab:env:info, or the Admin area Dashboard.
2. Upgrade official packages to 19.5.3, 19.4.5, 19.3.7 or 19.2.10, which also fix CVE-2026-110264; at minimum reach 19.4.2, 19.3.5 or 19.2.8.
3. If you build GitLab from source or in your own image, also upgrade Ruby to 3.3.13, 3.4.12 or 4.0.9 and confirm with ruby -v inside the running container.
4. Until patched, restrict reach: turn off open sign-up and put the instance behind VPN or SSO; this narrows but does not close the unauthenticated path.
5. If you see the crash pattern below, treat the server as compromised: rebuild it, rotate gitlab-secrets.json, CI/CD variables, runner and access tokens, and reset passwords.

How to check if you are affected or compromised

• Look for repeated Puma worker crashes (Ruby [BUG] reports in /var/log/gitlab/puma/puma_stderr.log), bursts of 502 errors and failed CI jobs, as Alpine saw on Oct 20-21.
• Review recently registered accounts that submitted CI configurations or called the CI lint API soon after signing up.
• Deploy GitLab's six published detections, including Onigmo native worker crash, Graphql cilint hostile regexp and ci lint workhorse worker crash.
• Check outbound connections from the GitLab host, if logged; Alpine notes that a successful exploit leaves no crash and no trace in web logs.

What happened#

On October 12, 2026, GitLab fixed CVE-2026-97229, an integer overflow in how it compiles regular expressions from CI/CD configuration. In its advisory, GitLab says an unauthenticated user could "execute arbitrary code on the GitLab server" with a crafted regex in a CI configuration. The CVE record scores it 10.0 (CVSS 3.1) and limits it to GitLab 19.2 through 19.4. The bug sits in Onigmo, the regex engine inside Ruby. GitLab patches that Ruby in its own packages.

About a week later someone used it. Alpine Linux reports that an attacker registered a new account on its public GitLab on October 20. Over October 20 and 21 the attacker sent crafted CI configurations that crashed GitLab workers eight times. In four of those crashes the exploit got partway before failing. The attacker also downloaded Alpine's GitLab container image, which suggests they were tuning the exploit to that exact build. Alpine found no evidence of code execution but says it "cannot rule it out," so it rebuilt the server and reset all passwords and GitLab secret keys. It checked its packages and releases against records outside GitLab and found no tampering.

CISA added the CVE to the KEV catalog on October 29. Under BOD 26-04 it gave federal agencies until November 1, three days.

Who is affected#

Two groups:

• Self-managed GitLab CE/EE on 19.2 before 19.2.8, 19.3 before 19.3.5, or 19.4 before 19.4.2.
• GitLab built on stock Ruby, from source or in a custom container image. A newer GitLab version alone does not help here. Alpine's own image ran standard Ruby, so upgrading to GitLab 19.3.6 on October 22 left it exploitable. Alpine had also first installed 19.3.4 instead of the fixed 19.3.5. The Ruby team shipped the fix on October 23 in Ruby 3.3.13, 3.4.12 and 4.0.9.

Ruby says other applications are affected only if they compile regexes from attacker-controlled strings, for example Regexp.new(params[:q]) or /#{input}/. Regexp.timeout does not protect against these bugs, and limiting pattern length is not reliable either.

Do you really need to act?#

Yes, if you run a self-managed GitLab that untrusted people can reach. Exploitation is confirmed, the target was a well-run open-source project, and the attacker went back on October 25 and 26 to try again. Alpine's attack also shows two ways to think you are patched when you are not: a near-miss version number, and a build that never got GitLab's Ruby patch.

The risk is lower, but not zero, if the instance is reachable only over VPN by trusted staff. GitLab rates the flaw unauthenticated. Alpine's attacker used a freshly registered account, so open sign-up makes exploitation easier.

GitLab.com and Dedicated were patched before the advisory went out. Versions older than 19.2 are outside this CVE. They are still exposed to the related Org-mode flaw CVE-2026-110264, which goes back to GitLab 7.0, so they need upgrading anyway. The current October 29 releases fix both.

What to do now#

1. Check the exact version on every instance, including mirrors and test servers: sudo gitlab-rake gitlab:env:info. For Docker, run docker exec gitlab cat /opt/gitlab/embedded/service/gitlab-rails/VERSION.
2. Upgrade to the current releases from October 29: 19.5.3, 19.4.5, 19.3.7 or 19.2.10. They also include the October 21 Org-mode fix (CVE-2026-110264) and the eMudhra CA distrust.
3. If you build GitLab yourself, run ruby -v inside the running container. You need 3.3.13, 3.4.12 or 4.0.9 or later. Rebuild any image created before you changed Ruby.
4. Until you are patched, turn off open sign-up (Admin area, Settings, General, Sign-up restrictions) and put the instance behind VPN or SSO.
5. If you see the crash pattern described below, follow Alpine's lead: rebuild, then rotate gitlab-secrets.json, CI/CD variables, runner tokens and access tokens, and reset user passwords.

How to tell if you were hit#

Failed attempts are noisy. Alpine saw repeated worker crashes, 502 errors and failed CI jobs from one new account. Search /var/log/gitlab/puma/puma_stderr.log for Ruby [BUG] crash reports. Review accounts created since October 12 that submitted CI configurations or hit the CI lint API. GitLab has published six detections for self-managed instances, among them "Onigmo native worker crash," "Graphql cilint hostile regexp" and "ci lint workhorse worker crash."

A successful exploit is quiet. Alpine notes it "would leave no crash and no trace in web logs." If you have outbound connection or database logs, check them for connections you can't explain.

Timeline#

• Oct 12, 2026 — GitLab releases 19.4.2, 19.3.5 and 19.2.8 with the fix. GitLab.com and Dedicated are already patched.
• Oct 13, 2026 — The CVE record is published.
• Oct 20, 2026 — An attacker registers on Alpine's GitLab and starts sending crafted CI configurations. Eight worker crashes follow over two days.
• Oct 23, 2026 — Ruby ships 3.3.13, 3.4.12 and 4.0.9 with the Onigmo fixes. Alpine blocks the attacker's account.
• Oct 27, 2026 — Alpine closes its GitLab and rebuilds it on patched Ruby, then publishes its write-up on October 28.
• Oct 29, 2026 — CISA adds CVE-2026-97229 to KEV with a November 1 deadline. GitLab ships 19.5.3, 19.4.5, 19.3.7 and 19.2.10.
• Oct 30, 2026 — SecurityWeek reports the exploitation. Alpine updates its post: its GitLab, now on 19.3.7, is open again.

Vulnerability records

• CVE-2026-97229 · KEV 2026-10-29 · GitLab has remediated an issue in GitLab CE/EE affecting all versions from 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain…

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. GitLab — Patch release 19.4.2, 19.3.5, 19.2.8 (CVE-2026-97229) docs.gitlab.com
2. CVE.org — CVE-2026-97229 cve.org
3. CISA — Known Exploited Vulnerabilities Catalog cisa.gov
4. Alpine Linux — GitLab security incident (CVE-2026-97229) alpinelinux.org
5. Ruby — Regexp fixes for GitLab CVEs ruby-lang.org
6. GitLab — Patch release 19.5.3, 19.4.5, 19.3.7, 19.2.10, 19.1.10, 19.0.11, 18.11.14 docs.gitlab.com

Coverage and analysis

1. SecurityWeek — Max-severity GitLab vulnerability exploited against Alpine Linux securityweek.com