Blog
GitLab CVE-2026-110264: unauthenticated regex RCE and self-managed triage
GitLab’s 21 Oct 2026 critical patch fixes CVE-2026-110264 — CVSS 10 unauthenticated RCE via integer overflow in the regular expression compiler. Self-managed instances must upgrade; GitLab.com is already patched. Operator triage plus compromise-assessment cues.
Web apps · Operator triage
On 21 Oct 2026, GitLab shipped a critical patch release for CE/EE. The headline issue is CVE-2026-110264: under certain conditions, an unauthenticated user can execute arbitrary code on the GitLab server due to an integer overflow when compiling a specially crafted regular expression. GitLab rates it CVSS 10.0.
CERT-EU advisory 2026-019 (22 Oct 2026) restates the same fix set and explicitly recommends upgrading internet-facing assets and running a compromise assessment.
This is a self-managed fire drill. GitLab states GitLab.com is already patched; certain GitLab Dedicated tenants on listed internal builds already include the fixes.
Snapshot
| Field | Value |
|---|---|
| CVE | CVE-2026-110264 |
| Class | Integer overflow in regular expression compiler → unauthenticated RCE |
| CVSS | 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) |
| Editions | GitLab CE and EE |
| Long tail | All versions from 7.0 before the fixed trains (yes — that far back) |
| Fixed builds | 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3, 19.5.1 |
| GitLab.com | Already running patched version |
| Detection | GitLab published two rules: Onigmo native worker crash; Org mode render error burst |
Use the GitLab patch page for the authoritative version matrix. This post is engagement sequencing.
Why this jumps the queue mid-engagement
Source-control appliances sit on corporate perimeters and inside build networks. On authorized testing:
- Unauthenticated RCE on a forge is rarely “informational”
- Version sprawl is real — old 15.x/16.x self-managed boxes still show up
- “We use GitLab” may mean SaaS (already patched) or a dusty Omnibus VM (not)
Also in the same patch: high issues around OmniAuth-to-LDAP auto-linking account takeover and OAuth/OIDC discovery cache poisoning — secondary if you already hold a session or are testing IdP flows, but do not let them distract from 110264 on an internet-facing login page.
Triage questions
- In ROE? Self-managed GitLab CE/EE authorized (Omnibus, source, Helm, etc.)?
- SaaS or self-managed? GitLab.com / patched Dedicated ≠ customer appliance.
- Exact version? Against the fixed trains above —
Help → About/ deploy version endpoint. - Internet-facing? CERT-EU: prioritize exposure; still patch internal forges that hold crowns.
- What do you pause? Unfinished AD/web paths with evidence deserve a clean pause note — do not abandon them because CVSS hit 10.0 in the news.
Operator path
Loading diagram…
Evidence worth capturing
- Exact CE/EE version string and install type (Omnibus / Helm / source)
- Proof the instance is customer-hosted and in scope
- If testing the issue within authorization: keep payloads minimal; prefer version+exposure findings when ROE is tight
- For IR / post-patch: GitLab’s Onigmo native worker crash and Org mode render error burst detections (linked from the patch notes / CERT-EU)
Client-facing remediations (short)
- Upgrade self-managed GitLab to a fixed version in your train (18.11.13+ or matching 19.x patch)
- Prioritize internet-facing instances, then internal
- After upgrade: run compromise assessment using GitLab’s published detection rules — patch ≠ proof of non-compromise
- Note GitLab’s upgrade caveats: some trains include migrations; single-node upgrades may incur downtime
What not to write
- Treating GitLab.com tenants as vulnerable after the vendor patch statement
- Invented exploitation volume or ransomware attribution
- Bundling every medium/low issue from the patch table as equal to CVSS 10 RCE
- Completeness claims without confirming which GitLab instances exist in scope
Primary sources: GitLab critical patch release (21 Oct 2026) and CERT-EU 2026-019 (22 Oct 2026). Re-verify fixed versions there before you file.