GitLab integer overflow: CVE-2026-97229

GitLab fixed CVE-2026-97229 on 12 October 2026 in 19.4.2, 19.3.5 and 19.2.8. Alpine Linux and Ruby say the fix is a patch to the Ruby in GitLab's own packages, so a server on its own Ruby also needs Ruby 3.3.13, 3.4.12, 4.0.9 or later.

Reviewed 1 Nov 2026 · Written by Rising from the linked sources. This is a dated snapshot, so check the official records before acting.

What the flaw is

CVE-2026-97229 is an integer overflow, CWE-190, that GitLab labels critical and scores 10.0 on CVSS 3.1. GitLab says that, under certain conditions, it could allow an unauthenticated user to execute arbitrary code on the GitLab server through a crafted regular expression, a pattern used to match text, in a CI/CD configuration.

Ruby places the bug in Onigmo, its regular expression engine, as an overflow in the size of a compiled pattern. According to Ruby, GitLab passes user-supplied patterns to the compiler, and GitLab found that crafted ones could corrupt memory at that stage and lead to remote code execution.

GitLab credits joaxcar, reporting through its HackerOne bug bounty program. Ruby names the same researcher as Johan Carlsson.

Affected and fixed versions

GitLab lists Community and Enterprise Edition 19.2 before 19.2.8, 19.3 before 19.3.5 and 19.4 before 19.4.2, and released those three fixes on 12 October 2026. It says all deployment types are affected when an entry names none, as this one does. The CVE record marks versions outside those ranges as unaffected and does not explain why the range starts at 19.2.

19.3.5 is the first fixed 19.3 release. GitLab's edit history shows the advisory named 19.3.4 as the fix when first published on 12 October and changed to 19.3.5 the same day, after adding a note that 19.3.4 had a merge request page bug. The CVE record, published on 13 October, gives 19.3.5. A 30 October Cyber Security News report still gives the old 19.3.4 range. Treat 19.3.4 as affected.

GitLab says GitLab.com runs the patched version and that every GitLab Dedicated tenant was patched with an internal release before the advisory was published. It does not say whether either service was exposed before patching, or whether either saw attempts.

Servers on their own Ruby

Ruby says the GitLab releases carry the fix as a patch to GitLab's bundled Ruby. GitLab's 12 October notes list that change under bug fixes, as a regular expression program size patch for Ruby 3.3 and 3.4 in its omnibus and cloud native image builds. The CVE entry in the advisory does not mention it. Alpine Linux says GitLab applies the patch only in its official packages, so a server built from source or in a custom image also needs a fixed Ruby.

The first upstream releases with this fix are 4.0.8, released on 22 October, and 3.4.12 and 3.3.13, released on 23 October. Ruby recommends 4.0.9, 3.4.12, 3.3.13 or later, and its table shows 4.0.9 as the first 4.0 release that also fixes the bug behind CVE-2026-110264. Its notice lists no fix for a series older than 3.3, and says 3.3.13 carries these fixes as an exception to that series' security maintenance phase.

Alpine says its own image stayed vulnerable on GitLab 19.3.6 because it used standard Ruby. The alpinelinux/gitlab image published on 27 October has Ruby 3.3.13, and Alpine says older tags, and 19.3.6 images pulled before that date, are vulnerable. Its distribution packages get the fix through apk upgrade: Ruby 3.4.12 on Alpine 3.22, 3.23, 3.24 and edge, and Ruby 3.3.13 on Alpine 3.21.

Exposure outside GitLab depends on compiling a regular expression from a string an attacker controls, Ruby says, and applications that only use patterns their own developers wrote are not affected. Regexp.timeout does not protect against the bugs. Limiting pattern length is not reliable either, because some can be triggered by short patterns. In its 23 October notice Ruby says it has requested no CVE identifiers of its own, and it tells users to track these bugs under GitLab's.

Whether an attacker needs an account

GitLab scores the flaw as needing no privileges and no user interaction, and its text describes an unauthenticated user. It does not say what the conditions are, and Censys noted on 13 October that neither GitLab nor NVD had published them.

Rapid7 reports a narrower route. In its testing, code execution required a crafted CI/CD configuration already committed to a public project by the attacker, and only the final request needed no credentials. An ordinary account can meet that requirement on instances where new users can register and create projects, Rapid7 says. It sees that step as at odds with GitLab's no-privileges rating, and does not know how the privately reported route gets around it.

Alpine Linux reports that a newly registered account sent the crafted CI configurations in the attack on its instance. Alpine does not say whether an account was required.

CVE-2026-93577, which Ruby lists under the same fix, is one GitLab describes as needing an authenticated user. GitLab scored it 9.9 and fixed it on 23 September, and neither GitLab nor Ruby explains the difference. None of these sources says whether an instance with sign-up closed and no public projects is safe. GitLab's policy is to make vulnerability issues public 90 days after the patch release.

What to do

Upgrade self-managed GitLab to at least 19.5.1, 19.4.3, 19.3.6 or 19.2.9, which also cover CVE-2026-110264. The 12 October releases leave that flaw open. It is a separate CVSS 10.0 regular expression compiler overflow affecting versions from 7.0, and GitLab fixed it on 21 October in those releases and in 19.1.9, 19.0.10 and 18.11.13. The next release, dated 29 October in GitLab's patch release feed, is 19.5.3, 19.4.5, 19.3.7, 19.2.10, 19.1.10, 19.0.11 and 18.11.14. GitLab says it skipped 19.5.2 and 19.4.4.

GitLab says the 12 October release includes database migrations. Single-node instances have downtime until they finish, and multi-node instances can avoid downtime with its zero-downtime procedures.

GitLab's advisory lists no workaround. If an upgrade must wait, Rapid7's temporary measures are to limit anonymous access to public projects and to keep untrusted users from creating them or writing to them. Rapid7 says those measures apply only to the route it showed, and the compiler stays vulnerable. Censys recommends restricting inbound access to the GitLab web interface.

What to check

GitLab added six threat detections for self-managed instances to the advisory on 21 October, according to the page's edit history. They cover worker crashes and CI regular expression activity, and the advisory links each rule.

Alpine's signals were worker crashes, 502 errors and failed CI jobs. It also says a working exploit would neither crash a worker nor show up in web logs.

Alpine lost background job logs and the old container's filesystem from the attack day, and neither it nor its hosting provider logged outbound connections. Its planned changes include logging those connections and database connections, with retention beyond 14 days. CISA's forensic triage guidance for federal agencies says to collect evidence before patching where possible, because patching may put artifacts at risk.

GitLab's advisory gives no guidance on rotating secrets or rebuilding. Alpine treated its instance as compromised and rebuilt it. It lists what could have been exposed if the attack succeeded: user details, password hashes, 2FA secrets, CI/CD variables, runner tokens, webhook, integration and push mirror credentials, hashed personal access tokens, and private repositories with confidential issues and merge requests. It reset passwords and 2FA, replaced GitLab's secret keys and its SSH host keys, invalidated personal access tokens, and told maintainers to treat CI/CD variable values and webhook and push mirror secrets as possibly exposed.

Exploitation so far

CISA added CVE-2026-97229 to its Known Exploited Vulnerabilities catalog on 29 October, and its alert says the addition rests on evidence of active exploitation. The alert and catalog entry name no attackers, victims or scale, and the entry lists ransomware use as unknown. The due date for US federal civilian agencies is 1 November, with a forensic triage required under Binding Operational Directive 26-04. CISA says the directive binds only those agencies and encourages other organizations to prioritize catalog entries.

Alpine Linux reports attempts against its GitLab instance on 20 and 21 October, when it ran 19.3.4 after what it calls a mistaken upgrade on 13 October. Worker processes crashed 8 times. Alpine says 4 of those crashes came from attempts that progressed further before failing. It reads the attacker's download of its GitLab container image as an effort to fit the exploit to its build, and says further attempts on 25 and 26 October failed. It found no evidence that attacker code ran and says it cannot rule that out. SecurityWeek describes the attack as failed, which is firmer than Alpine's own statement.

Alpine closed GitLab to the public on 27 October, rebuilt it, and reopened it on 29 October on 19.3.7 with Ruby 3.3.13. It says its checks found no tampering with the aports repository, packages or the 21 October releases, and that the keys it signs with have never been stored on the GitLab server. Those checks ran on 24 October and cover commits from 20 to 22 October and packages built up to 24 October. Alpine says it is extending them to 27 October.

Rapid7 says it reproduced code execution as GitLab's git user on the official 19.4.1 CE Linux amd64 image, and that the same input failed on 19.4.2. That is a lab result. Its advisory links a proof-of-concept exploit, which Censys dates to 13 October. The Metasploit Framework, a penetration testing tool, merged an exploit module for this CVE on 30 October, according to the pull request record.

On 13 October Censys said it knew of no exploitation in the wild and that GitLab's advisory does not mention the question, and Help Net Security reported Rapid7 as saying none was confirmed. BleepingComputer reports that GitLab released the detections after detecting attempts. GitLab's advisory does not say so.

Internet exposure

Censys reported on 13 October that it detected 82,454 GitLab hosts and 205,541 web properties, excluding entries labelled as honeypots. Of those, 25,766 hosts (31 percent) and 79,224 web properties (39 percent) ran an affected version. The count comes from detected software versions, and the advisory gives no scan time.

BleepingComputer reported on 30 October that Shadowserver tracks nearly 2,800 internet-exposed GitLab Community Edition instances and does not say how many are secured. That figure is Community Edition only, and Censys's search covers any GitLab it detects.

What is not known

No source dates the first exploitation. Alpine's 20 October attempt is the earliest dated one. CISA does not say what evidence it relied on or whether Alpine's incident is part of it.

No source establishes that an attacker ran code on a GitLab server in the wild, reports mass exploitation or names an attacker. CISA's catalog note says other products can potentially be affected by the same Ruby overflow, and it names none.

Settings