On 12 October 2026 GitLab shipped a critical patch release, versions 19.4.2, 19.3.5 and 19.2.8, for Community and Enterprise Editions. The headline fix is CVE-2026-97229, an integer overflow in the CI/CD regular expression compiler that GitLab says "could have allowed an unauthenticated user to execute arbitrary code on the GitLab server". It carries a CVSS 3.1 score of 10.0, and the release fixes 23 other security issues alongside it.
GitLab.com was already running the fix when the release went out, and GitLab says all Dedicated tenants were patched through an internal release beforehand. Self-managed instances are the ones that need action.
What's affected
CVE-2026-97229 affects GitLab CE and EE:
| Release line | Affected | Fixed in |
|---|---|---|
| 19.4 | before 19.4.2 | 19.4.2 |
| 19.3 | before 19.3.5 | 19.3.5 |
| 19.2 | 19.2.0 to 19.2.7 | 19.2.8 |
Versions before 19.2 are not listed as affected by this CVE. GitLab's description is short: the bug is triggered "via a specially crafted regular expression in a CI/CD configuration, due to insufficient regular expression validation", and the vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. GitLab publishes the underlying issues on its tracker 90 days after the fix, so the technical detail is not public yet. The reporter is joaxcar, through GitLab's HackerOne program.
Several of the other fixes in the same release also touch CI/CD and platform integrations:
- CVE-2026-16301 (CVSS 8.5): a user with the Developer role could run pipelines on protected branches through the downstream pipeline creation service. Affects 18.7 onward.
- CVE-2026-14814 (CVSS 8.2): poisoned cache responses for raw repository files could make a targeted user's pipeline run attacker content and expose protected environment variables. Affects all versions before the fixed releases.
- CVE-2026-81839 (CVSS 7.7, EE): stale scheduled pipeline execution policy records let pipelines run in a transferred project with the new group's privileges.
- CVE-2026-7767 (CVSS 5.8): an open redirect in the Kubernetes proxy could send authentication tokens to an unintended server when a user controls a Kubernetes agent. Affects 13.11 onward.
- CVE-2026-5954 and CVE-2026-103549: two authorization bugs in the package registry.
How to check if you're exposed
Find the exact version each instance runs. On an Omnibus (Linux package) install:
sudo gitlab-rake gitlab:env:info | grep -i "^GitLab information" -A 3
# or
cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
For the Docker image:
docker exec -it gitlab cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
For the Helm chart, check the deployed app version:
helm list -A | grep -i gitlab
You can also call the version API with any personal access token:
curl -s -H "PRIVATE-TOKEN: $TOKEN" https://gitlab.example.com/api/v4/version
Any instance on 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 CVSS 10 bug. Instances on older lines are not exposed to CVE-2026-97229 but are still missing the other fixes, several of which go back years (CVE-2026-101168 in GitLab Pages reaches back to 12.0).
Don't forget the instances nobody thinks of: a staging GitLab, a DR replica, an old instance kept for read-only history. If it's reachable from a network an attacker can reach, it counts.
What to do now
- Upgrade every self-managed instance to 19.4.2, 19.3.5 or 19.2.8, depending on your line. GitLab notes that the patch includes database migrations, so single-node instances will see downtime while they run. Multi-node instances can follow the zero-downtime procedure, and 19.3.5 also carries post-deploy migrations.
- If you're on 19.3.4, the upgrade also fixes a bug that broke merge request pages when the Ona integration was enabled.
- If you can't patch today, reduce who can reach the instance. Put it behind a VPN or an IP allowlist, and turn off public sign-up so the set of people who can create projects and push CI configuration stays small. GitLab hasn't published a configuration workaround for CVE-2026-97229, so treat this as risk reduction, not a fix.
- Rotate secrets after patching if the instance was exposed to the internet on an affected version. Code execution on the GitLab server reaches CI/CD variables, runner registration tokens and deploy keys. Start with protected variables that hold cloud credentials.
- Review protected branch pipelines for runs you can't explain, given CVE-2026-16301. In the UI, filter pipelines by protected branch and look for triggers from downstream pipelines started by Developer accounts.
Why it matters
A self-managed GitLab instance is a build system, a secrets store and a source repository in one process. A CVSS 10 bug in the CI/CD configuration parser goes straight to the part of the platform that holds deployment credentials. The fact that the input is a regular expression is a reminder that "configuration" is code too, and that parsers for it need the same hostile-input testing as any network service.
The patch-day pattern matters as well. GitLab's SaaS and Dedicated customers were protected before disclosure, which is normal for a vendor that runs its own product. Self-managed customers carry the window between release and upgrade themselves, and that window is where attackers aim once a fix can be diffed.
Try it yourself
Pick one GitLab instance and write down three facts: its version, who can reach it from the internet, and which CI/CD variables are marked protected. If you can't answer the second question in a few minutes, that's your first fix. Then add the instance to whatever asset inventory drives your patching, so the next critical release finds it automatically.
Click through it at your own pace, or open it full screen.
Quick check
Is a GitLab 18.11 instance affected by CVE-2026-97229?
No. GitLab lists 19.2 before 19.2.8, 19.3 before 19.3.5 and 19.4 before 19.4.2 as affected. An 18.11 instance still misses the other fixes in the release, so it should move to a supported, patched line.
Does a GitLab.com user need to do anything?
Not for the server fix. GitLab says GitLab.com was already running the patched version, and Dedicated tenants were patched before the release was published.
Why rotate CI/CD variables after patching?
Patching closes the hole but does nothing about secrets that may have been read while the instance was exposed. Code execution on the server can reach stored CI/CD variables and tokens, so rotating them limits the damage of any compromise you didn't see.
