GitLab regex flaws CVE-2026-97229 and CVE-2026-110264: why a GitLab update alone is not always enough

As of 8 November 2026. First published 1 November; updated with the Metasploit module, EPSS, newer releases and Censys details on the second flaw.

Summary

• CVE-2026-97229 (CVSS 10.0): integer overflow in the regex compiler for CI/CD configurations, code execution on the GitLab server. Fixed on 12 October, actively exploited, in CISA’s KEV catalogue since 29 October, with a Metasploit module since 30 October.
• CVE-2026-110264 (CVSS 10.0): a further integer overflow in the regex compiler, affecting every version since GitLab 7.0. Fixed on 21 October. No confirmed exploitation so far, not in KEV.
• Anyone who only updated to 19.4.2, 19.3.5 or 19.2.8 in October is not protected against the second flaw.
• Anyone running GitLab from source or in their own containers with a separate Ruby must update Ruby as well. That is exactly where Alpine Linux went wrong.
• Current releases per version line (28 October): 19.5.3, 19.4.5, 19.3.7, 19.2.10, 19.1.10, 19.0.11, 18.11.14. They additionally address CVE-2026-111943 (removal of trust for compromised eMudhra CA certificates).

Two flaws, one component.

Both vulnerabilities lie in the compilation of regular expressions that GitLab evaluates in CI/CD configurations, among other places. Both were reported by the same researcher (handle joaxcar) through GitLab’s bug bounty programme – following two other critical flaws GitLab had closed on 23 September with 19.4.1, 19.3.3 and 19.2.7. Four critical reports from one source in five weeks suggest the regex path has not been fully explored yet. GitLab rates both at 10.0 and exploitable without authentication (AV:N/AC:L/PR:N/UI:N/S:C).

In practice the bar is slightly higher than the vector suggests: Rapid7’s public proof of concept for CVE-2026-97229 (13 October) needs write access to a public project in order to commit a crafted .gitlab-ci.yml and a file path containing UTF-8 characters. Only the final CI lint request is unauthenticated. For CVE-2026-110264, Censys describes a similar route via a crafted .org file in a public project. On instances with open self-registration and project creation, however, that bar does not exist. In both cases the code runs as the git user – with access to gitlab-secrets.json, all CI/CD variables, runner and access tokens, and read and write access to every repository on the instance.

The 21 October releases close both flaws plus ten further vulnerabilities, including an authentication weakness in OmniAuth LDAP auto-linking (CVE-2026-15723, CVSS 8.2). GitLab.com and GitLab Dedicated are patched.

Exploitation and tooling.

The situation has worsened since the first version of this post. On 30 October a Metasploit module for CVE-2026-97229 was merged; the exploit is no longer tied to Rapid7’s demonstration but part of the standard toolkit. FIRST’s EPSS model scores the flaw at 0.27 (98th percentile, as of 1 November). CISA set a deadline of 1 November for federal agencies and, under BOD 26-04, requires initial forensic triage, not just the patch.

For CVE-2026-110264 there is so far no confirmed exploitation and no KEV entry. Given the much wider affected version range and more than 11,000 exposed instances, that is more a question of time than of feasibility. No attacker IP addresses, user agents or payload hashes from real-world attacks have been published for either flaw.

The Alpine Linux case: patched and still vulnerable.

On 28 October Alpine Linux published a detailed report on an attack against the project’s own GitLab instance:

• On 13 October Alpine accidentally installed 19.3.4 instead of 19.3.5.
• On 20 and 21 October a newly registered account submitted crafted CI configurations; workers crashed repeatedly. The attacker also downloaded Alpine’s GitLab container image, apparently to tune the exploit to the exact build.
• On 22 October Alpine updated to 19.3.6. The instance remained vulnerable.
• On 25 and 26 October further attempts were blocked.

The reason: the bug sits in Onigmo, Ruby’s regex engine. GitLab built the fix into the Ruby it ships in its Linux packages and official container images. Alpine runs GitLab with the distribution’s Ruby, which only received the fix with Ruby 3.3.13, 3.4.12 and 4.0.9 on 23 October. Ruby 3.2 is end-of-life and gets no fix.

Alpine found no evidence of successful code execution but cannot rule it out, because a successful exploit leaves no trace in the web logs and outbound connections were not logged. The instance was therefore treated as compromised, rebuilt, and all passwords and secret keys were replaced. According to the report, Alpine’s packages and signing keys are not affected.

What to do now.

1. Check the version (under /help or via the API at /api/v4/version) and update to the current release of your line: 19.5.3, 19.4.5, 19.3.7, 19.2.10, 19.1.10, 19.0.11 or 18.11.14. The minimum against both regex flaws is the 21 October releases. The releases include database migrations; single-node instances will see a short outage.
2. Check Ruby if GitLab does not come from the official packages or images (source installation, own containers, distribution packages):

   ruby -v
   

   Required is Ruby 3.3.13, 3.4.12, 4.0.9 or newer. In the official Linux packages the bundled Ruby lives under /opt/gitlab/embedded/bin/ruby and is updated together with GitLab.
3. Reduce the attack surface if the update is not possible immediately: disable self-registration or make it approval-based, remove project creation and write access for untrusted users, restrict anonymous access to public projects. That closes only the known Rapid7 route, not the flaw itself.
4. Initial forensic triage on every instance reachable from the internet between 12 October and the update – CISA requires it for federal agencies, and the reasoning applies to every operator: a successful exploit leaves nothing in the web logs.

Detection.

GitLab has published Sigma rules for self-managed instances – six for CVE-2026-97229, two for CVE-2026-110264 – covering, among other things, Onigmo worker crashes, suspicious CI regex warnings and GraphQL ciLint requests, and unusually long file paths with non-ASCII characters. On the host, look at:

• files in /tmp owned by the git user
• unexpected child processes of Puma or Sidekiq
• outbound connections from the GitLab server
• modified crontabs or SSH keys of the git user
• clusters of 502 errors and crashing workers in the period in question

In XIEM the Sigma rules map to Wazuh rules for production_json.log, workhorse.log and sidekiq.log; the host indicators are covered by FIM on /tmp and the git home directories plus the agent’s process telemetry. Egress logging of the GitLab hosts is the data source Alpine was missing.

If there are signs of code execution: treat the instance as compromised and replace gitlab-secrets.json, all CI/CD variables, runner tokens, access tokens and integration credentials.

Context.

At the end of October Shadowserver counted around 39,000 reachable GitLab instances per day, more than 1,000 of them vulnerable to CVE-2026-97229 and more than 11,300 to CVE-2026-110264 – close to 30 percent of the visible population. A GitLab server is rarely just a source-code archive: it holds CI/CD variables with cloud and deployment credentials, runner tokens and signing processes. A compromised GitLab server is therefore a direct route into your own software supply chain and into the systems the pipelines deploy to. How far a chain of stolen pipeline secrets can reach was demonstrated by TeamPCP in March.

For entities subject to NIS2, such systems fall under the requirements for supply-chain security and vulnerability management. Alpine’s recommendation can be adopted as is: apply critical GitLab releases within a day, check with every release whether components such as Ruby need separate updates, log outbound connections and retain logs for longer than 14 days.