BREAKING: GitLab critical patch fixes no-login code execution on self-managed servers (CVE-2026-97229)

A self-managed GitLab server on 19.2, 19.3 or 19.4 can be made to run an attacker's code with no account at all. GitLab shipped an out-of-band critical patch release on 2026-10-12 (19.4.2, 19.3.5 and 19.2.8) for CVE-2026-97229, an integer overflow in the regular expression compiler that CI/CD configuration goes through. GitLab rates it CVSS 10.0 with no privileges and no user interaction. If you run your own GitLab, upgrade tonight.

The same release fixes 23 other security issues, five of them rated high. This post is our operator read of the GitLab critical patch release notes and the CVE record; the HOL Guard evidence pack for CVE-2026-97229 is the source record.

How to fix

Upgrade to the patch for the minor version you are on. These are patch releases inside your current minor version, so they do not need an upgrade-path stop. One catch for 19.3: the release notes list CVE-2026-84284 (no-login read of private work items) as affecting all 19.3 versions, so 19.3.5 does not close it. If you can, go to 19.4.2.

# Omnibus on Debian/Ubuntu (swap gitlab-ce / -ce.0 for Community Edition)
sudo apt-get update
sudo apt-get install gitlab-ee=19.4.2-ee.0      # or 19.3.5-ee.0 / 19.2.8-ee.0

# Omnibus on RHEL/Alma/Rocky
sudo dnf install gitlab-ee-19.4.2-ee.0.el9

# Docker
docker pull gitlab/gitlab-ee:19.4.2-ee.0

Helm chart users: move to the chart release that ships GitLab 19.4.2, 19.3.5 or 19.2.8. GitLab.com is already patched and GitLab Dedicated customers do not need to do anything.

GitLab published no workaround. If you cannot upgrade in the next few hours, the only thing that lowers exposure is who can reach the instance at all: put it behind your VPN or an IP allowlist and turn off open sign-up until the package lands. That is our suggestion, not GitLab's, and it is not a fix.

One operator check

Confirm what is actually running, not what the package manager thinks it installed:

# Omnibus or Docker (inside the container)
cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

# From anywhere, with a token
curl -s -H "PRIVATE-TOKEN: $GITLAB_TOKEN" https://gitlab.example.com/api/v4/version

Anything at 19.2.0 to 19.2.7, 19.3.0 to 19.3.4, or 19.4.0 to 19.4.1 is exposed to the critical bug. After the upgrade, run sudo gitlab-ctl status and make sure Puma and Sidekiq came back, then re-check the version file.

Where the bug lives

GitLab's write-up is short: a specially crafted regular expression in a CI/CD configuration can overflow an integer in the regular expression compiler and give code execution on the server. CI/CD config takes regexes in a lot of places (rules:if with =~, branch and tag filters), and the server has to compile them to evaluate a pipeline.

The bug-fix list in the same release is the more interesting tell. Both 19.4.2 and 19.3.5 add a "Ruby regexp program size patch for 3.3 and 3.4" and a "Ruby regexp repeat-range double-free patch." Our read is that at least part of the fix lives in the Ruby runtime GitLab bundles, not only in Rails code. That matters for one group in particular: if you run GitLab from source on your own Ruby, upgrading the GitLab code may not carry those runtime patches. Omnibus, Docker and Helm installs get them with the package.

GitLab does not explain how someone with no account gets a CI config in front of the compiler. The CVE references two HackerOne reports from the same researcher (joaxcar), both still private, and GitLab makes security issues public 90 days after the fix. Until then, treat the CVSS vector at face value: network, no login, full compromise of the server and everything on it, including repository contents, CI/CD variables and runner registration tokens.

The other high-severity fixes in this release

• CVE-2026-92883 (8.7): stored cross-site scripting through syntax highlighting in a crafted repository. Affects 19.1 and later.
• CVE-2026-16301 (8.5): a user with the Developer role could run pipelines on protected branches through the downstream pipeline service. Protected branches are usually where deploy secrets live. Affects 18.7 and later.
• CVE-2026-14814 (8.2): poisoned cached raw-file responses could make other users' pipelines run crafted content and expose protected variables. Affects all versions before the fixed ones.
• CVE-2026-81839 (7.7, EE): scheduled pipeline execution policy records were not cleaned up on project transfer, so pipelines could run with the new group's privileges.
• CVE-2026-96893 (7.3, EE): crafted content could be injected into GitLab Duo Agent Platform instructions, causing commands to run that are attributed to other users. This is the prompt-injection problem every coding agent has, landing inside the forge itself. Affects 19.1 and later.

Three of the medium fixes (CVE-2026-16275, CVE-2026-84284, CVE-2026-85529) let someone with no account read confidential notes or private work item content through GraphQL. On a public-facing instance those are worth the upgrade by themselves.

Who is not in scope

• GitLab.com users. GitLab says the SaaS is already running the patched version.
• GitLab Dedicated. No customer action needed.
• 19.1 and earlier, for the critical bug only. The affected range for CVE-2026-97229 starts at 19.2. Older servers are still hit by CVE-2026-14814 and, from 18.7, CVE-2026-16301, and they are outside the three patched trains, so they need to move to 19.2.8 or later anyway.
• GitLab Runner as a product. The advisory names GitLab CE/EE only and does not list GitLab Runner. Runners still execute whatever a compromised server sends them, so patch the server first.

What this is not

It is not on the CISA Known Exploited Vulnerabilities list (catalog 2026.10.08 at publish time), and GitLab does not report exploitation in the wild. That is a statement about tonight, not a reason to wait. The last GitLab bug we covered, the commits API path traversal that landed on KEV, ended up there.

References

• GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8
• CVE-2026-97229 record
• GitLab work item 630686 (private until disclosure)