On this page (7 sections)

CVE-2026-97229 is a critical flaw (CVSS 10.0) in GitLab Community Edition and Enterprise Edition. It could let an unauthenticated attacker run code on the GitLab server by submitting a specially crafted regular expression in a CI/CD configuration. CISA added it to its Known Exploited Vulnerabilities (KEV) catalog on 2026-10-29, and The Hacker News reports that the listing is tied to an attempted attack on the Alpine Linux project's GitLab server.

If you run a self-managed GitLab instance, this is a patch-now item. There is also a catch: according to Alpine's account, upgrading GitLab alone did not close the hole on a server that used standard Ruby. Read the sections on affected versions and the Ruby requirement before you consider the job finished.

What happened

GitLab shipped critical patch releases 19.4.2, 19.3.5 and 19.2.8 on October 12, 2026, according to the GitLab patch release notes. Many issues were fixed in that batch. The only one rated Critical is an integer overflow in the CI/CD regular expression compiler, tracked as CVE-2026-97229. The CVE was published on 2026-10-13.

On 2026-10-29 CISA added the flaw to KEV, with a due date of 2026-11-01 for federal civilian agencies, per the CISA catalog entry. CISA lists use in ransomware campaigns as "Unknown" and marks forensic triage as required under its BOD 26-04 directive.

The Alpine Linux incident

The public evidence of exploitation comes from Alpine Linux, which said on October 28 that an attacker had tried to exploit its own GitLab server. As The Hacker News reported from Alpine's disclosure, events went like this:

  • Alpine moved to GitLab 19.3.4 on October 13 rather than 19.3.5, which it described as a mistake.
  • A newly registered account sent crafted CI configurations on October 20 and 21. Worker processes crashed eight times, and in four of those crashes the attempt got partway through before failing at the next step.
  • The attacker also downloaded Alpine's GitLab container image. Alpine said this suggests the exploit was being tuned to its exact build.
  • Alpine blocked the account on October 23. Further attempts on October 25 and 26 failed.
  • Alpine found no evidence of success but could not rule it out, so it treated the server as compromised, rebuilt it and reset every account's password.

Alpine said its aports repository, its packages and the October 21 releases were not tampered with, and that its signing keys were never stored on the GitLab server. This is the only incident described in the research. We have no information about how widely the flaw is being exploited elsewhere.

Technical details

GitLab uses Ruby to compile the regular expressions found in CI configurations. According to Alpine, as relayed by The Hacker News, the bug sits in Onigmo, the regular expression engine built into Ruby. The weakness class is CWE-190, Integer Overflow or Wraparound: a calculation yields a number too big for the space reserved for it, so the value wraps around to something small or negative. Code that assumes the result is always larger than the input can then behave in unintended ways. Here, the vendor says the outcome could be arbitrary code execution, and Alpine observed worker crashes.

The CVSS v3.1 vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. In plain terms, it is reachable over the network with low complexity, needs no privileges and no user interaction, and has high impact on confidentiality, integrity and availability. The GitHub advisory shows an EPSS score of 26.569% (98th percentile), a modeled estimate of exploitation likelihood over the next 30 days.

GitLab thanks the researcher joaxcar for reporting the issue through its HackerOne bug bounty program. The vendor describes the flaw as something that "under certain conditions" could allow code execution. We are not reproducing exploit details, and defenders do not need them.

Who is affected

Per the vendor advisory, these GitLab CE and EE ranges are affected:

Affected and fixed GitLab versions for CVE-2026-97229
Release lineAffectedFixed in
19.219.2 before 19.2.819.2.8
19.319.3 before 19.3.519.3.5
19.419.4 before 19.4.219.4.2

GitLab states that GitLab.com already runs the patched version and that all GitLab Dedicated tenants were patched before the release went out. The people who must act run self-managed instances. The advisory says that when no deployment type is named, all types (Omnibus, source, Helm chart and so on) are affected.

The Ruby catch: Alpine reports that GitLab's fix works by patching the Ruby bundled in GitLab's own Linux packages and container images. Alpine's image used standard Ruby, so moving to GitLab 19.3.6 did not fix the flaw there. Per Alpine, servers that run GitLab on their own Ruby (built from source or in a custom container image) need Ruby 3.3.13, 3.4.12, 4.0.9 or later in addition to the GitLab upgrade. CISA also notes that other products could potentially be affected by the same underlying Ruby/Onigmo issue.

How to check your exposure

  1. List every GitLab instance you operate, including old test servers, hosts that serve runners and instances run by other teams.
  2. Read the version on each one from the admin area or your package manager. Anything on 19.2 before 19.2.8, 19.3 before 19.3.5 or 19.4 before 19.4.2 is vulnerable.
  3. Work out where Ruby comes from. With the official GitLab Omnibus package or official container images, the fix is bundled in the patched release. With a source build or custom image, compare your Ruby version with the fixed versions above.
  4. Check whether the instance is reachable from the internet and whether open registration lets strangers create accounts. In the Alpine case, the probing came from a newly registered account.
  5. Review logs for the signs described below.

What to do now

  1. Upgrade to 19.4.2, 19.3.5, 19.2.8 or later. GitLab strongly recommends that all self-managed installations upgrade immediately.
  2. If you supply your own Ruby, move to 3.3.13, 3.4.12, 4.0.9 or later, then rebuild and redeploy. If you use a third-party GitLab image, ask its maintainer and pull a rebuilt one. Alpine said users of its alpinelinux/gitlab image needed to pull 19.3.6 again.
  3. Verify the result rather than assuming it. Alpine upgraded and still found its server vulnerable.
  4. Limit exposure while you patch: put the instance behind a VPN or allowlist, and turn off open sign-up if you do not need it.
  5. If you were exposed on an unpatched version, consider the instance potentially compromised and follow your incident process. CISA marks forensic triage as required for this entry.
  6. If compromise is plausible, rotate the secrets that live on the server.

Alpine listed what could have been exposed had its attack succeeded: user emails, names and IP addresses, password hashes, 2FA secrets, CI/CD variables and runner tokens, webhook, integration and push mirror credentials, personal access tokens, and private repositories with confidential issues and merge requests. That list works as a rotation checklist for your own instance. For response steps, see website hacked: what to do.

Detection and monitoring

GitLab says it has released six threat detections for self-managed customers, with names such as "Onigmo native worker crash" and "Graphql cilint hostile regexp" appearing in its advisory. The research text we have is truncated, so see the GitLab advisory for the full list.

Signals worth looking for, based on the Alpine incident:

  • Repeated GitLab worker crashes and unexplained 502 errors.
  • CI jobs failing without a clear cause.
  • New accounts submitting unusual CI configuration files.
  • Downloads of your GitLab container image by accounts with no reason to need it.

Know the limits. Alpine noted that a successful exploit would leave no crash and no trace in web logs, and that some of its own logs, including background job logs, were gone, with no outbound connection logging in place. Keep outbound network logging and sensible log retention so you can investigate later.

A free SSL certificate checker and monitoring for certificate, DNS and uptime changes can help you notice when a rebuilt or re-exposed server behaves differently than before. They do not detect this vulnerability, so patching and log review remain the core steps.

Timeline

Key dates (2026)
DateEvent
October 12GitLab releases 19.4.2, 19.3.5 and 19.2.8
October 13CVE-2026-97229 published; Alpine upgrades to 19.3.4
October 20-21Crafted CI configurations crash Alpine's GitLab workers
October 22-23Ruby fixed versions come out, per The Hacker News; Alpine upgrades to 19.3.6 on October 22 and blocks the account on October 23
October 25-26Further attacker attempts fail; Alpine finds the server still vulnerable
October 28Alpine finishes the rebuild and discloses the incident
October 29CISA adds CVE-2026-97229 to KEV
November 1CISA due date for federal civilian agencies

Sources

This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.

  1. CVE-2026-97229 - GitHub Advisory Databasegithub.com
  2. GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8 | GitLab Docsdocs.gitlab.com
  3. Known Exploited Vulnerabilities Catalog | CISAcisa.gov
  4. GitLab Community Edition and Enterprise Edition Integer Overflow or Wraparound Vulnerability (CVE-2026-97229) is being actively exploitednvd.nist.gov ·
  5. CISA Adds Actively Exploited GitLab RCE and Cisco Firewall DoS Flaws to KEVthehackernews.com ·
  6. Attacker Tried to Exploit Alpine Linux’s GitLab via CVSS 10.0 Flaw Its Ruby Left Openthehackernews.com ·
  • GitLab
  • CVE-2026-97229
  • CISA KEV
  • remote code execution
  • Ruby