2 GitLab CE/EE Flaws Exploited, Including CVE-2026-97229 (CVSS 10.0)

I noticed that CISA had added GitLab to KEV for the second time in two months: CVE-2026-97229 on 29 Oct 2026, following CVE-2026-85706, which was added on 11 Sep. Both have the maximum CVSS score of 10.0, and neither requires authentication. I have put them together in this post, with a clear breakdown of which branches need which versions, because the versions that fix the first vulnerability do not cover the second.

What happened

CVE-2026-85706 is a path traversal vulnerability in the repository commits API, according to GitLab. The causes are insufficient path restrictions and an API that does not enforce authentication. As a result, an unauthenticated user can read arbitrary files on the server. GitLab released patches on 10 Sep 2026 as 19.3.2, 19.2.6 and 19.1.8, then backported them to older branches on 23 Sep as 19.0.9 and 18.11.12. CISA added it to KEV the following day (11 Sep), requiring US federal agencies to remediate it by 14 Sep.

CVE-2026-97229 is an integer overflow in the CI/CD regular expression compiler. An unauthenticated user can submit a specially crafted regular expression in CI/CD settings and execute code on the server. GitLab identifies insufficient regex validation as the cause. It was fixed in the patch release dated 12 Oct 2026. CISA added it to KEV on 29 Oct, with a remediation deadline of 1 Nov, and the KEV notes say that other products may be affected by the same Ruby/Onigmo integer overflow bug.

The latter vulnerability originates in Ruby's regex engine, according to the ruby-lang.org advisory (23 Oct 2026). Applications that compile regexes from attacker-controlled text (such as Regexp.new) are at risk. Applications that use only developer-written regexes are not affected, and Regexp.timeout does not protect against it.

Severity

Both score 10.0 under CVSS 3.1, according to GitLab. The first has the vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N, meaning high impact on both confidentiality and integrity, but no impact on availability. The second has the vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, meaning high impact on all three. Both can be exploited over the network, have low attack complexity, require no privileges, and require no user interaction.

CISA states in the KEV table that both have been exploited in the wild. The ransomware field is Unknown for both. I opened the KEV file CISA released on 3 Nov 2026 and checked it myself. CVE-2026-110264 (the fourth vulnerability, covered in the next section) is not in KEV according to the same file.

The file-read capability in the first vulnerability is no small matter: GitLab itself released a detection that watches for attempts to read gitlab.yml, which means the system configuration file is an expected target.

Who is affected, and which versions to upgrade to

GitLab states that version 19.3.4 has a bug on the merge request page when the Ona integration is enabled, fixed in 19.3.5. The version that fixes CVE-2026-97229 on the 19.3 branch is 19.3.5, not 19.3.4, matching the title of GitLab's patch release page (19.4.2, 19.3.5, 19.2.8).

I recommend the "latest branch patch" column as the target because GitLab released another set on 21 Oct (19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13) fixing CVE-2026-110264, the fourth vulnerability in the regex compiler family, also with a CVSS score of 10.0. This one affects a broader range, from 7.0 onward up to the fixed versions. GitLab also states that anyone using their own Ruby instead of the one bundled with the official package must upgrade Ruby to 3.3.13, 3.4.12, 4.0.9 or later, because the fix is in Ruby rather than GitLab's code.

Earlier, on 23 Sep, 19.4.1 / 19.3.3 / 19.2.7 fixed two regex vulnerabilities that require the attacker to be logged in (CVE-2026-89078 double free and CVE-2026-93577 integer overflow, scoring 9.9). Anyone who stopped at those versions is still affected by CVE-2026-97229.

GitLab.com has been patched, and GitLab Dedicated was patched internally before the announcement. Customers in these two groups do not need to do anything. Self-managed users need to upgrade themselves.

How to fix it

1. Check the current version and compare it with the table above to see which version your branch needs
2. Back up with gitlab-backup before every upgrade
3. Upgrade to the latest branch patch and upgrade Ruby too if you use your own Ruby
4. Check for evidence going back to before the patch if the server was exposed to the internet

Check the current version first.

sudo gitlab-rake gitlab:env:info | head -20
cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
dpkg -l | grep -E 'gitlab-(ce|ee)'

Then back up and upgrade. The example below is for branch 19.4. Change the version number according to the table above, and change ce to ee if you use Enterprise.

sudo gitlab-backup create
sudo apt update
apt-cache madison gitlab-ce | head
sudo apt install gitlab-ce=19.4.3-ce.0
sudo gitlab-ctl status

If you run Docker, change the tag and recreate the container using the same volumes.

docker pull gitlab/gitlab-ce:19.4.3-ce.0

A point to note from GitLab's patch release page: this patch set includes database migrations. A single-node instance must accept downtime during migration, while multi-node systems can follow GitLab's zero-downtime upgrade procedure. If you need to cross several minor versions, check GitLab's upgrade path first. I have not worked through that path here.

Check whether you have been affected

GitLab publishes threat detections for self-managed instances on its patch release pages (the CVE-2026-97229 page links to the gitlab-security-oss/tldr repository). There are three for CVE-2026-85706: LFI attempts to read gitlab.yml, LFI through the metadata.path parameter, and LFI through path enumeration. There are six for CVE-2026-97229: Onigmo native worker crash, GraphQL CI lint hostile regexp, CI regexp oversized non-ASCII path, CI regexp guard rejection, CI lint Workhorse worker crash, and CI lint scripted client error burst. GitLab's page lists their names and links to their definitions, but does not explain which logs to inspect.

GitLab has not published IOCs as paths or requests that can be matched with grep. I have therefore provided a rough search example of my own, not GitLab's. It works only when the parameters appear in the URL; if they are sent in the body, they will not appear in the access log.

# ตัวอย่างหยาบ (ของผมเอง) path ของ Omnibus: คำขอไปที่ commits API ที่มีชื่อไฟล์ระบบหรือ ../
sudo zgrep -hiE 'repository/commits' /var/log/gitlab/nginx/gitlab_access.log* \
  | grep -iE 'gitlab\.yml|secrets|%2e%2e|\.\./|/etc/' | head -50

# worker ล้ม หรือ 500 ต่อเนื่องที่ CI lint / GraphQL
sudo grep -hE '"status":500' /var/log/gitlab/gitlab-rails/production_json.log* | grep -iE 'lint|graphql' | tail -20

If you find actual evidence or suspect that the server was exposed to the internet while unpatched, you should assume that local files readable by GitLab may have leaked. I would consider rotating secrets stored on the server, such as values in /etc/gitlab/gitlab-secrets.json and runner tokens. This is my decision, not GitLab's recommendation. For a full server inspection procedure, see Debian server security scan.

GitLab states that details of this set of vulnerabilities will become public in its issue tracker 90 days after the release, which means attackers will have more information to learn from.

Personally, if GitLab is accessible from the internet, I upgrade as soon as I read about it, without waiting for a maintenance window, because there are two KEV entries and neither requires authentication. If it is accessible only on the internal network, waiting for the normal maintenance cycle may be acceptable, but it should not take more than a week. Whether to go straight to the latest patch for the current branch or move to a newer branch depends on each site's readiness.

P.S. GitLab released its next patch set on 29 Oct 2026 (19.5.3, 19.4.5, 19.3.7, 19.2.10, 19.1.10, 19.0.11, 18.11.14). That set's patch release page lists only CVE-2026-111943, covering GitLab's removal of trust for 8 eMudhra intermediate CA certificates whose private keys had leaked. It is unrelated to regex. The table above still lists versions that cover the CVEs in this post, but if you are upgrading further, you can use the versions from the 29 Oct set directly. Self-hosted GitLab Runner must be upgraded separately (that release page specifies 19.5.1).

Sources: GitLab Critical Patch Release 19.3.2 / 19.2.6 / 19.1.8 (https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-3-2-released/), 19.4.1 / 19.3.3 / 19.2.7 (https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-1-released/), 19.4.2 / 19.3.5 / 19.2.8 (https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/), 19.5.1 (https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/), CISA Known Exploited Vulnerabilities Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog), Ruby advisory "Regexp fixes for GitLab CVEs" (https://www.ruby-lang.org/en/news/2026/10/23/regexp-fixes-for-gitlab-cves). Information current as of 5 Nov 2026; KEV checked against the file CISA released on 3 Nov 2026. I will come back and update this later.