GitLab CVE-2026-110264: Critical Unauthenticated RCE in Self-Managed GitLab CE/EE. Upgrade to the Fixed Versions Now

TL;DR: On 21 October 2026, GitLab released critical patch versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13 for GitLab Community Edition (CE) and Enterprise Edition (EE). They fix CVE-2026-110264, an integer overflow in GitLab's regular expression compiler. GitLab says that "under certain conditions" it "could have allowed an unauthenticated user to execute arbitrary code on the GitLab server" (GitLab patch release). GitLab scores it CVSS 10.0 (Critical). What to do: upgrade every self-managed GitLab CE/EE instance to the fixed version for its release line, starting with internet-facing instances.

What lowers the urgency for most readers:

• Self-managed only. GitLab says "GitLab.com is already running the patched version". GitLab Dedicated tenants on 19.3.5-internal0 and 19.4.2-internal0 or later "already include these fixes and do not need to take action."
• No exploitation reported by GitLab. GitLab's release post does not say whether the flaw has been exploited, and we found no CISA, CERT-EU or NCSC-NL report of exploitation.
• Not in CISA KEV. CVE-2026-110264 is not in CISA's Known Exploited Vulnerabilities catalog (live feed, catalogVersion 2026.10.21, checked 22 October 2026, 02:29 Cyprus time (UTC+3)).

One thing to check: if you patched for GitLab's 12 October critical release (19.4.2, 19.3.5 or 19.2.8), you are still in range for this flaw. Those versions are below the new fixed versions.

Technical Information

GitLab lists CVE-2026-110264 as "Integer Overflow issue in Regular Expression Compiler impacts GitLab CE/EE" and rates it Critical. In GitLab's words, the issue "under certain conditions, could have allowed an unauthenticated user to execute arbitrary code on the GitLab server due to integer overflow when compiling a specially crafted regular expression." GitLab has not published those conditions in its release post.

• GitLab CVSS 3.1: 10.0, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H (network, low complexity, no privileges, no user interaction, scope changed).
• Editions: GitLab CE and EE. GitLab says that when no deployment type is named, "all types are affected" (Omnibus, source, Helm chart and so on).
• Reporter: joaxcar, through GitLab's HackerOne bug bounty program.
• Detection content from GitLab: GitLab published two detection rules for self-managed instances, "Onigmo native worker crash" and "Org mode render error burst". These place the issue in the Onigmo regular expression engine that Ruby uses, reached through GitLab's rendering of Org-mode (.org) files. GitLab warns that a successful exploit "does not reliably crash", so a missing alert does not prove an instance is clean.

Timeline

All times are Cyprus time (UTC+3).

• 12 October 2026: GitLab fixes a separate CVSS 10.0 regular expression flaw in the CI/CD path, CVE-2026-97229, in 19.4.2, 19.3.5 and 19.2.8 (GitLab). CERT-EU covered that release in advisory 2026-016.
• 20 October 2026: GitLab's detection rules for CVE-2026-110264 are dated this day.
• 21 October 2026: GitLab publishes the critical patch release fixing CVE-2026-110264, with backports to 18.11.13, 19.0.10, 19.1.9 and 19.2.9.
• 22 October 2026, 02:29: Rescana checks the public records. There is no CVE record on cve.org yet, no NVD entry, no CISA KEV listing, and no CISA or CERT-EU alert for CVE-2026-110264.

CVE, NVD and KEV status (checked 22 October 2026, 02:29 Cyprus time (UTC+3))

• cve.org: the CVE record has not been published yet (as of 02:29 Cyprus time, the CVE API returns the error "CVE_RECORD_DNE"). So there is no CISA-ADP SSVC exploitation entry yet.
• NVD: no entry yet, so NVD has no score of its own. The only score is GitLab's CVSS 10.0.
• CISA KEV: not listed (catalogVersion 2026.10.21, released 21 October 2026, 17:04 Cyprus time).
• National CERTs: we found no CISA, CERT-EU or NCSC-NL alert for CVE-2026-110264. CERT-EU covered the 12 October release in advisory 2026-016.

How far back the affected range goes

GitLab lists the flaw as affecting "all versions from 7.0". GitLab's v7.0.0 tag is dated 20 June 2014, so the affected range covers about 12 years of GitLab releases.

Affected Product Versions

From GitLab's advisory: "GitLab CE/EE: all versions from 7.0 before 18.11.13, 19.0 before 19.0.10, 19.1 before 19.1.9, 19.2 before 19.2.9, 19.3 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1".

Versions patched on 12 October (19.4.2, 19.3.5 and 19.2.8) are still affected: each is below the fixed version for its line (19.4.3, 19.3.6 and 19.2.9).

GitLab's "Org mode render error burst" detection rule, dated 20 October, lists only 19.5.1, 19.4.3 and 19.3.6 as fixes. The release post, published on 21 October, also lists the backports to 19.2.9, 19.1.9, 19.0.10 and 18.11.13. This table follows the release post.

Workaround and Mitigation

1. Upgrade. GitLab "strongly recommend[s] that all self-managed GitLab installations be upgraded to one of these versions immediately." It did not publish a workaround in its release post. GitLab's fix for older lines is a backport. Instances on versions older than 18.11 need to move through GitLab's supported upgrade path, including its required upgrade stops, to 18.11.13 or later (GitLab upgrade paths). (The upgrade-path note is Rescana guidance.)
2. Plan for migrations. GitLab says 19.4.3 and 19.3.6 include regular database migrations, and 19.4.3 also includes post-deploy migrations. Single-node instances will have downtime while migrations run. Multi-node instances can use GitLab's zero-downtime upgrade procedure.
3. Reduce exposure until you patch. GitLab's detection guidance advises: "Until patched, reduce public visibility where possible". Prioritize internet-facing instances and instances with public projects. (The prioritization order is Rescana guidance, in line with CERT-EU's advice for the 12 October release.)
4. Turn on detection. Deploy GitLab's two detection rules and make sure your log pipeline collects the logs they use. GitLab says the absence of a hit "never clears an attempt or a success."
5. If you see hits, follow your incident response process. GitLab's detection guidance says: "If you find signs of code execution, treat the instance as compromised". In that case it advises rotating the instance secrets, all CI/CD variables, all runner tokens and all access tokens.

Indicators of Compromise

GitLab has not published IoCs for CVE-2026-110264. It has published behavioral detection rules (linked above), not network indicators. We found no published IoCs from CISA or CERT-EU.

Why this matters for vendor risk

Self-managed GitLab often holds a vendor's source code, CI/CD secrets and deployment credentials. If one of your software vendors runs an unpatched self-managed GitLab server that can be reached from the internet, this flaw could let an attacker into the system that builds the software you receive. That risk is there even though GitLab.com customers need not act, and even though GitLab has not reported exploitation. You cannot see a vendor's internal GitLab version from the outside, so ask your critical software and managed service vendors:

• Do you run self-managed GitLab CE or EE, including for internal tooling or CI/CD?
• Have you upgraded every instance to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13? If you patched on 12 October, did you upgrade again?
• Have you deployed GitLab's detection rules, and have they fired?

What we will update: We will update this post when the CVE record is published on cve.org (including any CISA-ADP SSVC exploitation entry), when NVD scores the flaw, if CISA adds it to KEV, if GitLab reports exploitation or publishes workarounds or IoCs, or if CISA, CERT-EU or NCSC issues an alert.

Sources

• GitLab (vendor), "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" (21 Oct 2026): https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/
• GitLab Security, TLDR detection rules for CVE-2026-110264 (20 Oct 2026): "Onigmo native worker crash" https://gitlab.com/gitlab-security-oss/tldr/-/blob/main/Detections/platforms/GitLab/Vulnerability%20Detections/onigmo_native_worker_crash.md?ref_type=heads and "Org mode render error burst" https://gitlab.com/gitlab-security-oss/tldr/-/blob/main/Detections/platforms/GitLab/Vulnerability%20Detections/org_mode_render_error_burst.md?ref_type=heads
• GitLab (vendor), "GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8" (12 Oct 2026): https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/
• GitLab (vendor), upgrade paths documentation: https://docs.gitlab.com/update/upgrade_paths/
• CISA, Known Exploited Vulnerabilities catalog (live JSON feed): https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
• CERT-EU, Security Advisory 2026-016, "Critical Vulnerability in GitLab CE and EE" (12 Oct 2026; covers CVE-2026-97229): https://cert.europa.eu/publications/security-advisories/2026-016/

Forward this to your TPRM owner: If any of your vendors build software or run CI/CD on self-managed GitLab, ask them today whether every instance is on 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13. Ask too whether instances patched for the 12 October release were upgraded again, and when they will confirm in writing.

Want a fast, evidence-based view of which vendors in your supply chain are exposed to flaws like this, and how quickly they respond? Book a demo.