CVE Tools
Track your stack
A GitLab CI/CD pipeline diagram with a crack running through one node, revealing a tangled regex pattern underneath like exposed wiring — dark, technical, server-rack mood

A CVSS 10 GitLab RCE Already Crashed Alpine Linux's Own GitLab Server Eight Times Before CISA Added It to KEV

CVE-2026-97229 lives in Ruby's bundled regex engine, not GitLab's own code — which is exactly why bumping GitLab's version number didn't fix it for everyone. Alpine's own incident report shows what happens when that gap meets a live attacker.

CVE Tools5 min read

CVE-2026-97229In CISA KEVEPSS today 65%, 99th percentileCVSS 10.0Open the record

CVE-2026-97229 is a maximum-severity (CVSS 10.0) remote code execution flaw that GitLab patched on October 12, 2026 — but the actual bug isn't in GitLab's own code. It's in Onigmo, the regular-expression engine bundled inside Ruby, and GitLab's fix works by shipping a patched Ruby alongside the new GitLab version. An instance running its own, non-bundled Ruby build can upgrade GitLab's version number and stay exactly as exploitable. Alpine Linux found that out the hard way: an attacker crashed its self-hosted GitLab's worker processes eight times on October 20–21 while the instance sat on a version that looked patched. CISA added the CVE to its Known Exploited Vulnerabilities catalog on October 29 with a due date of November 1 — a deadline that has already passed.

10.0CVSS scoreAV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
27.3%EPSS98th percentile
8GitLab worker crashesAlpine's instance, Oct 20–21
Nov 1, 2026CISA KEV due datealready passed as of this writing
CVE-2026-97229Integer Overflow or Wraparound in GitLabEPSS 65%CVSS 10.0CVE-2026-110264Integer Overflow or Wraparound in GitLabEPSS 1.3%CVSS 10.0

What the bug actually is

GitLab's advisory describes it as an integer overflow (CWE-190) in the CI/CD regular-expression compiler. Rapid7's independent technical writeup fills in the mechanism: a crafted regex first compiles fine under ASCII validation, but when it's later re-evaluated against a UTF-8 repository path, Ruby's Onigmo engine recompiles it for the new encoding after those checks already passed — overflowing the compiler's program-size calculation and corrupting control flow. The practical requirement is lower than the CVSS vector implies: an attacker needs to commit a crafted .gitlab-ci.yml plus a UTF-8 repository path to a branch in a public project — a bar that disappears entirely on instances that allow open self-registration and project creation. The flaw was reported through GitLab's bug bounty by researcher Johan Carlsson (joaxcar).

Two bugs, one engine — and only one is in KEV

CVEAffected versionsFixed inEPSSCISA KEV
CVE-2026-9722919.2 < 19.2.8 · 19.3 < 19.3.5 · 19.4 < 19.4.219.2.8 / 19.3.5 / 19.4.2 (Oct 12)27.3% (98th pct)Yes — added Oct 29, 2026
CVE-2026-1102647.0 < 18.11.13 · 19.0 < 19.0.10 · 19.1 < 19.1.9 · 19.2 < 19.2.9 · 19.3 < 19.3.6 · 19.4 < 19.4.3 · 19.5 < 19.5.119.2.9 / 19.3.6 / 19.4.3 / 19.5.1 (Oct 21)1.3% (71st pct)Not as of Nov 3, 2026

Why 'upgrade GitLab' wasn't the whole fix for Alpine

GitLab's official packages / Docker / Helm
  • Ships a patched Ruby build bundled with the GitLab version bump
  • GitLab's own two Ruby-regexp patches — 'program size' and 'repeat-range double-free' — apply automatically
  • A version upgrade to 19.2.8 / 19.3.5 / 19.4.2 is sufficient on its own
This is the deployment path GitLab's advisory assumes.
A custom or distro-packaged Ruby (Alpine's case)
  • GitLab's bundled Ruby patch never reaches a build that links the system Ruby instead
  • Bumping GitLab's version number alone leaves the vulnerable Onigmo engine in place
  • Only a separate Ruby upgrade — to 3.3.13 / 3.4.12 / 4.0.9+, shipped upstream Oct 23 — actually closes the hole
Alpine upgraded twice — to 19.3.4, then 19.3.6 — and stayed exploitable until it rebuilt on a patched Ruby.

Alpine's incident, day by day

Alpine Linux published its own incident report on the attack against its self-hosted GitLab instance. The timeline below is drawn directly from that report.

  1. GitLab ships the fix
    19.2.8 / 19.3.5 / 19.4.2 released.
  2. CVE published — Alpine upgrades to the wrong version
    Alpine updates to GitLab 19.3.4 by mistake, instead of the fixed 19.3.5.
  3. Attack
    A newly registered account submits crafted CI/CD configurations; GitLab worker processes crash 8 times — in 4 of those crashes the attacker got partway through the exploit chain and failed at the next step. The attacker also pulls Alpine's own GitLab container image, apparently to tune the exploit to that exact build.
  4. Alpine upgrades again, to 19.3.6
    Still exploitable: the real fix lives in a bundled Ruby patch that Alpine's own Ruby build doesn't carry.
  5. Attacker's account blocked; Ruby ships its own fix
    Ruby 3.3.13 / 3.4.12 / 4.0.9 land upstream the same day.
  6. Attacker returns, fails to regain access
    Alpine separately discovers the instance is still vulnerable despite two upgrades.
  7. Full rebuild
    GitLab closed to everyone but developers and build servers; the instance is rebuilt from scratch, all passwords reset, GitLab's secret keys replaced.
  8. Reopened on 19.3.7 with a patched Ruby — same day CISA adds the CVE to KEV
    Alpine confirms the aports repository, packages, and the Oct 20–22 release builds were not tampered with; no package-signing keys were ever stored on the GitLab server.

A gap in our own exploit tracking, for the record

CVSS 10 doesn't predict likelihood — and this isn't the only GitLab CVE to prove it

CVE-2026-97229 is GitLab's second entry on CISA's KEV list in six weeks. The first, CVE-2026-85706 (a path-traversal bug we covered in September), also scored a flat 10.0 — but its EPSS sits at 97.4%, nearly four times higher than CVE-2026-97229's 27.3%, despite both being confirmed KEV exploitation. CVE-2026-110264, same CVSS ceiling, same code path, sits at just 1.3% and isn't in KEV at all yet. Three CVSS-10.0 GitLab bugs, three very different likelihood signals — a pattern visible across the vendor's recent history on our trends dashboard.

Three CVSS-10.0 GitLab CVEs, by EPSS
CVE-2026-85706 (Sep, …97.4CVE-2026-97229 (Oct, …27.3CVE-2026-110264 (Oct,…1.3
LabelValue
CVE-2026-85706 (Sep, in KEV)97.4
CVE-2026-97229 (Oct, in KEV)27.3
CVE-2026-110264 (Oct, not in KEV)1.3

What to actually do

  1. If you run GitLab's official Linux package, Docker image, or Helm chart: upgrade straight to 19.2.9 / 19.3.6 / 19.4.3 / 19.5.1 — the versions that close both CVE-2026-97229 and CVE-2026-110264 — not just the October 12 releases.
  2. If GitLab runs against your own Ruby build (a custom container, a distro package, a from-source install): check the Ruby version separately. You need 3.3.13, 3.4.12, or 4.0.9+ regardless of which GitLab version you're on — a version-number match on GitLab alone proves nothing.
  3. If you can't patch immediately on an internet-facing instance, disable open self-registration and public project creation — GitLab's advisory lists this as the interim mitigation, since it removes the unauthenticated path to pushing a crafted .gitlab-ci.yml.
  4. Look for GitLab's own threat-detection rules published alongside the fix — six in total, including one named 'Onigmo native worker crash' that matches the exact failure mode Alpine saw.
  5. If a GitLab instance you administer was exposed during the window and missed the Nov 1 KEV deadline, treat it as overdue, not low-priority — CISA's forensic-triage expectation under BOD 26-04 applies to any instance that was exposed, not only ones still unpatched today.

Data as of November 3, 2026

Sources: GitLab patch release notes, 19.4.2 · Alpine Linux's incident report, CVE-2026-97229 · Ruby security advisory on the Onigmo regexp fixes · CISA Known Exploited Vulnerabilities catalog, CVE-2026-97229 · Rapid7, CVE-2026-97229 technical analysis and PoC · NVD, CVE-2026-97229