# GitLab CVE-2026-110264: A Second CVSS 10 RCE in Nine Days. Patch to 19.5.1 URL: https://www.devopsness.com/blog/gitlab-cve-2026-110264-regex-rce-patch-now Author: Kiril Urbonas Published: 2026-10-31 Updated: 2026-10-31 Categories: DevOps Tags: Gitlab, Security, CVE, DevSecOps, Incident Response Summary: An unauthenticated regex-compiler RCE reaching back to GitLab 7.0, no workaround, and backports on older branches that fix only the critical bug. The exact version per branch and the commands to get there. --- # GitLab CVE-2026-110264: A Second CVSS 10 RCE in Nine Days. Patch to 19.5.1 Upgrade self-managed GitLab to 19.5.1, 19.4.3 or 19.3.6 today. CVE-2026-110264, released October 21, 2026, is a CVSS 10.0 bug that lets an unauthenticated attacker run code on the server by making GitLab compile a crafted regular expression. Every CE and EE version from 7.0 onward is affected, and GitLab lists no workaround. > [!VERIFIED] > GitLab 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13, against the GitLab 19.5.1 and 19.4.2 patch release notes, the GitLab package upgrade docs and CSA Singapore alert AL-2026-152. Checked October 2026. This is the second perfect-10 regex bug in nine days. On October 12, GitLab shipped 19.4.2, 19.3.5 and 19.2.8 for CVE-2026-97229, a CI/CD regex compiler overflow from the same researcher, joaxcar. If you patched on October 12 and stopped, you are still exposed: 19.4.2 is below the new 19.4.3 floor. GitLab.com is already patched, and Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 and later have the fixes. Everything below is as of October 31, 2026. ## Am I affected? Check the version in 30 seconds You are affected if you run self-managed GitLab (Omnibus, Docker, Helm or source) on any version below the fixed release for your branch. Get the exact version first: ```bash # On the GitLab host (Omnibus or Docker exec) $ sudo gitlab-rake gitlab:env:info | grep -A3 'GitLab information' # From anywhere, with a token $ curl -s --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \ https://gitlab.example.com/api/v4/version # Docker: the image tag is the truth, not the compose file you think you deployed $ docker inspect --format '{{.Config.Image}}' gitlab ``` Then find your branch in this table. The column that matters most is the third one. | Your branch | Upgrade to | Fixes CVE-2026-110264 | Fixes the other 11 CVEs | Migrations in this patch | |---|---|---|---|---| | 19.5 | 19.5.1 | Yes | Yes | None listed | | 19.4 | 19.4.3 | Yes | Yes | Regular and post-deploy | | 19.3 | 19.3.6 | Yes | Yes | Regular | | 19.2 | 19.2.9 | Yes | No | None listed | | 19.1 | 19.1.9 | Yes | No | None listed | | 19.0 | 19.0.10 | Yes | No | None listed | | 18.11 | 18.11.13 | Yes | No | None listed | | 18.10 or older | 18.11.13 at minimum, via your upgrade path | Only once there | No | Depends on path | The backports to 18.11 through 19.2 exist so nobody is left holding an unauthenticated RCE, but GitLab's advisory lists fixed versions for the other eleven issues only on 19.3.6, 19.4.3 and 19.5.1. On 19.2 or older, the critical hole closes while the high-severity account takeover below stays open. ## What the bug actually is GitLab's description is short on purpose: an integer overflow when compiling a specially crafted regular expression can let an unauthenticated user execute arbitrary code on the server. The vector is `AV:N/AC:L/PR:N/UI:N/S:C`, which means network-reachable, low complexity, no login, no user interaction, and the impact escapes the vulnerable component. The advisory does not name the library, but one of the two detection rules GitLab shipped is "Onigmo native worker crash", and Onigmo is Ruby's regex engine. That points at native code under Rails, which is why no application setting turns it off. The second rule, "Org mode render error burst", suggests Org-format file rendering is one path to the compiler; that is our reading, not GitLab's statement. Issue details normally go public 90 days after the fix, so expect more exploit interest in January. ## What to do now, in order 1. **Snapshot or back up.** The Omnibus package backs up the database automatically before installing a newer version unless `/etc/gitlab/skip-auto-backup` exists. Check that file is not there, or take your own backup. 2. **Pick the target from the table.** Default to the latest patch of your current minor so there is no required-stop math. 3. **Upgrade.** Pin the version so a mirror lag does not hand you something else: ```bash # Debian / Ubuntu, Enterprise Edition (use gitlab-ce and -ce.0 for CE) $ sudo apt update && sudo apt install gitlab-ee=19.5.1-ee.0 # RHEL / AlmaLinux / Oracle Linux 9 $ sudo dnf install gitlab-ee-19.5.1-ee.0.el9 # Amazon Linux 2023 $ sudo dnf install gitlab-ee-19.5.1-ee.0.amazon2023 # Docker: bump the tag, then recreate the container $ docker pull gitlab/gitlab-ee:19.5.1-ee.0 ``` 4. **Plan the downtime.** GitLab says single-node instances will have downtime because migrations must finish before GitLab starts. On 19.3.6 and 19.4.3 there are regular migrations, and 19.4.3 adds post-deploy migrations, so that window is longer than a restart. Multi-node installs can follow the zero-downtime procedure. 5. **Verify.** Re-run the version check above, then `sudo gitlab-rake gitlab:check SANITIZE=true` for a health pass. 6. **Hunt.** Load the two new detection rules into your SIEM and search back to at least October 12. A burst of Onigmo native crashes before you patched is an incident, not noise: rotate secrets the GitLab host can read (runner registration tokens, CI variables, deploy keys), and treat the box as compromised until you rule it out. ## The LDAP and SAML account takeover you should not skip The highest-rated companion fix is CVE-2026-15723, CVSS 8.2. With OmniAuth SAML and LDAP auto-linking both on, an authenticated user can take over an existing LDAP-backed account with no action from the victim, through improper sanitization in the LDAP email lookup. It affects every version from 10.1 and is fixed only on 19.3.6, 19.4.3 and 19.5.1. Check whether you are in the blast radius: ```bash $ sudo grep -nE "auto_link_(ldap|saml)_user|omniauth_auto_link" /etc/gitlab/gitlab.rb ``` If `gitlab_rails['omniauth_auto_link_ldap_user'] = true` shows up next to a SAML provider and you cannot reach 19.3.6 this week, turning that setting off and running `sudo gitlab-ctl reconfigure` breaks the exploit precondition. GitLab does not list that as an official workaround, and new SSO users will stop being linked to LDAP automatically, so tell your identity team before you flip it. The same release fixes CVE-2026-112212, a 7.5 cache poisoning in the OAuth and OIDC discovery endpoints, another reason to land on 19.3 or newer rather than a backport. ## Where this breaks A WAF rule will not save you: GitLab has not said which inputs reach the regex compiler, so there is no reliable pattern to block. Versions older than 18.11 have no direct fix, and jumping many minors means following GitLab's required upgrade stops, which can take a day on a large instance. If that is you, put the instance behind a VPN or allowlist today and run the upgrade path tomorrow. That shrinks the attack surface; it does not remove the bug. Our general triage for "critical, no workaround" CVEs is in [how we handle vulnerabilities in production](/blog/handling-vulnerabilities-in-production), and the same patch-tonight pattern played out with [PHP2Shell earlier this month](/blog/php2shell-cve-2026-109618-109619). If GitLab is also your CI, the [October 19 GitLab.com rate limits](/blog/gitlab-rate-limits-october-19-what-to-fix-now) are worth a look while you are in there. ## Questions people ask ### Is GitLab.com affected by CVE-2026-110264? No action is needed on GitLab.com, which GitLab says is already patched, and Dedicated tenants on 19.3.5-internal0, 19.4.2-internal0 or later already include the fixes. The risk sits entirely with self-managed CE and EE installations, including Docker and Helm deployments, from version 7.0 onward that have not moved to the fixed release for their branch. ### Is there a workaround if I can't upgrade GitLab today? GitLab provides none for CVE-2026-110264; its only guidance is to upgrade. The best interim step is cutting exposure: restrict the instance to a VPN or an IP allowlist so unauthenticated internet traffic cannot reach it. That reduces who can trigger the bug but does not fix it. Upgrade to the patch for your branch as soon as you can schedule the downtime. ### I patched to 19.4.2 on October 12. Am I safe? No. The October 12 release fixed CVE-2026-97229, a separate CVSS 10 regex bug in the CI/CD compiler. CVE-2026-110264 affects 19.4 before 19.4.3, 19.3 before 19.3.6 and 19.2 before 19.2.9, so every version shipped on October 12 is still vulnerable. Upgrade again, to 19.4.3 or 19.5.1, and plan for the migrations 19.4.3 runs. ## The call we'd make Patch every self-managed GitLab to 19.5.1 today, or to 19.4.3 or 19.3.6 if a minor jump needs change approval you cannot get by tonight. Treat the 18.11 to 19.2 backports as a stopgap measured in days, because they leave the LDAP takeover open. The caveat is downtime on single-node installs: announce a maintenance window, but do not wait for the weekend on an unauthenticated CVSS 10 with a sibling already published. ## Sources - [GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/) - [GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8 (CVE-2026-97229)](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/) - [GitLab docs: Upgrade a Linux package instance](https://docs.gitlab.com/update/package/) - [CSA Singapore AL-2026-152: Critical Vulnerability in GitLab](https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-152/)