Blog
GitLab vulnerabilities CVE-2026-110264 and CVE-2026-97229: am I affected and what should I do?
In October 2026 GitLab fixed a critical flaw in its regular expression compiler twice, both exploitable without login. If you updated after the first release, you have to update again. Here is what you need to know and do.
Published · Stackwatch team
What happened
In October 2026 GitLab fixed two critical vulnerabilities in its regular expression compiler, both rated CVSS 10.0 (CVSS 3.1, AV:N/AC:L/PR:N):
- CVE-2026-97229 (patch release of 12 October): "Integer Overflow issue in CI/CD Regular Expression Compiler". According to GitLab, under certain conditions an unauthenticated attacker could run arbitrary code on the GitLab server with a crafted regular expression in the CI/CD configuration.
- CVE-2026-110264 (patch release of 21 October): "Integer Overflow issue in Regular Expression Compiler". Again an integer overflow when compiling a crafted regular expression, again code execution without login. This time GitLab says the affected range goes back to version 7.0.
Important: if you updated to 19.4.2, 19.3.5 or 19.2.8 after the first release, you are not yet protected against CVE-2026-110264. That requires the versions of 21 October.
Self-managed instances (CE and EE) are affected. According to GitLab, GitLab.com already runs the fixes and GitLab Dedicated instances were patched before publication.
Affected and fixed versions
The second vulnerability, CVE-2026-110264, is the one that matters. The versions of 21 October fix both.
| Branch | Affected (CVE-2026-110264) | Fixed in |
|---|---|---|
| GitLab 19.5 | before 19.5.1 | 19.5.1 |
| GitLab 19.4 | before 19.4.3 | 19.4.3 |
| GitLab 19.3 | before 19.3.6 | 19.3.6 |
| GitLab 19.2 | before 19.2.9 | 19.2.9 |
| GitLab 19.1 | before 19.1.9 | 19.1.9 |
| GitLab 19.0 | before 19.0.10 | 19.0.10 |
| GitLab 18.11 | before 18.11.13 | 18.11.13 |
| GitLab 7.0 to 18.10 | yes | no fix, move to one of the versions above |
According to GitLab, CVE-2026-97229 only affects the 19.2 (before 19.2.8), 19.3 (before 19.3.5) and 19.4 (before 19.4.2) branches.
Is it being exploited?
- GitLab's two release posts say nothing about observed attacks. GitLab did publish detection rules for self-managed instances for both vulnerabilities, including "Onigmo native worker crash".
- Neither CVE is in CISA's KEV catalog (as of 25 October 2026).
No KEV entry does not mean "can wait": CVSS 10.0, no login required and an internet-facing service are exactly the combination attackers try first. How to prioritise such vulnerabilities is covered in the article on CVSS, EPSS and CISA KEV.
Am I affected? How to check
On the GitLab server (Omnibus installation):
sudo gitlab-rake gitlab:env:infoThe version is listed under "GitLab information". Alternatively:
cat /opt/gitlab/embedded/service/gitlab-rails/VERSIONIn the browser, the /help page of your instance shows the version (after signing in).
With Docker the version is in the image tag, for example:
docker ps --format '{{.Image}}' | grep gitlabgitlab/gitlab-ee:19.4.2-ee.0 is affected, gitlab/gitlab-ee:19.4.3-ee.0 is not. In repos with infrastructure code (Docker Compose, Helm, Ansible) the tag is usually right in the configuration.
Pitfalls
The first update is not enough. If you were quick on 12 October and moved to 19.4.2, 19.3.5 or 19.2.8, you have to update again.
Old branches get no fix. There is no patch release for versions before 18.11. The way out is an upgrade to a supported branch, possibly via several intermediate versions (follow GitLab's upgrade path).
Plan for downtime. Both releases include database migrations. According to GitLab, single-node instances are unavailable during the update, multi-node installations can update without downtime.
Pinned images. latest or a tag like 19.4 only picks up the new version on the next pull and restart. A fixed tag like 19.4.2-ee.0 stays vulnerable until you change it.
Package scanners don't see it. Dependabot and other SCA tools check your projects' dependencies, not the version of your GitLab server. More in the comparison with Dependabot.
What to do now
- List all self-managed GitLab instances, including test and legacy instances.
- Update to
19.5.1,19.4.3,19.3.6,19.2.9,19.1.9,19.0.10or18.11.13, depending on your branch. - Verify on the running instance with
gitlab-rake gitlab:env:infoor/help. - Apply the detection rules published by GitLab and review logs for worker crashes since 12 October if your instance was internet-facing.
If you can't patch right away
GitLab names no workaround in either post and recommends updating as soon as possible. Until then, only general measures reduce the risk:
- Take the instance off the public internet and make it reachable only via VPN or an IP allowlist. According to GitLab, both vulnerabilities can be exploited without login, so an attacker only needs to reach the instance.
- Enable GitLab's detection rules to see attack attempts.
These measures do not replace an update.
To see whether other components in your stack have open vulnerabilities, use the free stack check.
Sources
Frequently asked questions
What are CVE-2026-110264 and CVE-2026-97229?
Two critical flaws in the regular expression compiler of GitLab CE and EE, both rated CVSS 10.0. According to GitLab, an unauthenticated attacker can execute code on the GitLab server with a crafted regular expression.
Which GitLab versions are fixed?
The releases of 21 October 2026 fix both: 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 and 19.5.1. The releases of 12 October (19.2.8, 19.3.5, 19.4.2) only fix CVE-2026-97229.
Is GitLab.com affected?
No. According to GitLab, GitLab.com and GitLab Dedicated are already patched. Self-managed instances are affected.
How do I check my GitLab version?
On the server with sudo gitlab-rake gitlab:env:info or in the web interface at /help. If your version is below the fixed release for your branch, you are affected. There is no official workaround, only the update.