What happened

On October 12, 2026, GitLab released 19.4.2, 19.3.5 and 19.2.8 to fix CVE-2026-97229, which it describes as an issue that "under certain conditions, could have allowed an unauthenticated user to execute arbitrary code on the GitLab server via a specially crafted regular expression in a CI/CD configuration." The vendor score is CVSS 3.1 10.0. Rapid7 reproduced code execution on 19.4.1 and explains the conditions: an attacker must be able to commit a malicious .gitlab-ci.yml to a branch in a public project, and "on GitLab instances where new users can self register and create projects, this constraint is removed." GitLab's own detection notes describe it as a bypass of an earlier, authenticated fix (CVE-2026-93577).

Nine days later, GitLab released 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13 for CVE-2026-110264, also rated 10.0. This one reaches back to GitLab 7.0. GitLab renders .org files with the org-ruby gem, which builds a second regular expression from a keyword in the file's #+TODO: line. A keyword repeated more than 32,767 times overflows a 16-bit counter in Onigmo and leads to an out-of-bounds write, and from there to a shell command as the git user. GitLab's detection notes put it plainly: "The attack needs no authentication, only one public project that can hold the .org payload."

Both were reported through HackerOne by researcher joaxcar, part of a run of four critical GitLab regex bugs since September 23, The Hacker News reports. Ruby itself has now fixed the underlying engine bugs in 4.0.9, 3.4.12 and 3.3.13, with no fix for Ruby 3.2. GitLab.com runs the patched versions, and GitLab Dedicated tenants were patched before release. Neither CVE is on CISA's KEV catalog, and no exploitation in the wild has been reported. Rapid7 has published a detailed technical analysis of CVE-2026-97229.

Why it matters if you run public infrastructure

A self-managed GitLab holds source code, CI/CD variables, deploy keys and runner tokens, which makes code execution on it a path into every system it deploys to. The precondition for both bugs is a public project, and many instances have one: open-source mirrors, documentation, a demo project nobody remembers creating. With open sign-up, any visitor can make their own. These are also the kind of bug attackers move on quickly: CISA listed the CVE-2026-85706 path traversal as exploited on September 11, the day after GitLab patched it.

What to check this week

  1. Find every self-managed GitLab you expose, including old instances kept for archived projects. Check the version at /help while signed in, or with gitlab-rake gitlab:env:info.
  2. Upgrade to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13 (or later). These cover both CVEs. GitLab names no workaround.
  3. Until you can upgrade, shrink the precondition. Rapid7 suggests restricting anonymous access to public projects and stopping untrusted users from creating or writing to public projects. Turning off open sign-up and reducing public visibility both help. Neither fixes the underlying bug.
  4. Look for attempts. GitLab's security team published two detections. One looks for Ruby [BUG] crashes in puma_stderr.log or Sidekiq logs that show Onigmo or org-ruby frames. The other looks for one client causing five or more Org-mode render timeouts in exceptions_json.log within 30 minutes. GitLab warns that a successful exploit of CVE-2026-110264 "is quiet and does not reliably crash," so also scan repositories for .org files with oversized #+TODO: lines.
  5. If you find signs of compromise, GitLab's guidance is to rotate gitlab-secrets.json, CI/CD variables, runner tokens and access tokens.

How Attack Surface Scan covers this

Attack Surface Scan recognizes GitLab sign-in pages on hosts under your verified domains, including hosts found through certificate transparency logs, which is how a forgotten instance turns up. GitLab does not show its version to anonymous visitors, and our potential matches cover only CVEs on CISA's KEV catalog, so these two are not flagged as findings unless CISA lists them. The inventory still tells you where GitLab is exposed, which is the first step on the checklist above. We do not send exploit traffic. See Vulnerability matching for the details.

Sources