News Vulnerabilities & Zero-Days
Patch now: CVSS 10 GitLab flaw lets unauthenticated attackers run code, affecting every release back to 2014
GitLab has fixed CVE-2026-110264, a maximum-severity flaw that could let an unauthenticated attacker execute code on self-managed GitLab servers through a crafted regular expression. Every version from 7.0 onward is affected.
Key takeaways
- CVE-2026-110264 is a CVSS 10.0 GitLab flaw that could let unauthenticated attackers execute code.
- It is caused by an integer overflow when compiling a crafted regular expression.
- Every self-managed GitLab CE/EE version from 7.0 (2014) is affected.
- Fixes are in 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13; GitLab.com is already patched.
- GitLab does not report exploitation but has published detections for attempts.
GitLab released patches on 21 October 2026 for CVE-2026-110264, a critical vulnerability rated the maximum 10.0 on CVSS. GitLab says that under certain conditions an unauthenticated user could execute arbitrary code on a GitLab server.
What is the vulnerability? #
The flaw is an integer overflow that occurs when GitLab compiles a specially crafted regular expression. GitLab has not published the exact conditions needed to trigger it. The issue was reported by the researcher joaxcar through GitLab's HackerOne bug bounty program.
It affects all GitLab Community Edition (CE) and Enterprise Edition (EE) versions from 7.0 onward. GitLab 7.0 was released in 2014, so the flaw reaches back about 12 years.
Which versions fix it? #
| If you run | Upgrade to |
|---|---|
| 19.5 | 19.5.1 |
| 19.4 | 19.4.3 |
| 19.3 | 19.3.6 |
| 19.2 | 19.2.9 |
| 19.1 | 19.1.9 |
| 19.0 | 19.0.10 |
| 7.0 to 18.11 | 18.11.13 |
GitLab.com is already running the patched version, and GitLab Dedicated tenants on 19.3.5-internal0, 19.4.2-internal0 or later already include the fixes. Only self-managed installations need action.
Is it being exploited? #
GitLab's release notes do not report exploitation. GitLab has published two detections for self-managed customers to spot exploitation attempts, named "Onigmo native worker crash" and "Org mode render error burst".
What else was fixed? #
The same release fixes 11 other vulnerabilities, including two rated high:
| CVE | Issue | Severity |
|---|---|---|
| CVE-2026-15723 | Improper authentication in OmniAuth-to-LDAP auto-linking | High (8.2) |
| CVE-2026-112212 | Cache poisoning of OAuth/OIDC discovery endpoints | High (7.5) |
The rest are rated medium or low.
What should GitLab admins do? #
- Upgrade self-managed GitLab to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13 as soon as possible. GitLab "strongly recommend[s]" upgrading immediately.
- Patch internet-facing instances first.
- Enable or review GitLab's published detections for exploitation attempts, and check logs for repeated worker crashes since before you patched.
- If you run a very old GitLab version, plan an upgrade path to 18.11.13 or later, since every release back to 7.0 is affected.
Sources
Questions this raises
- Is GitLab.com affected?
- No action is needed. GitLab says GitLab.com already runs the patched version, and Dedicated tenants on the listed internal releases include the fixes.
- Does an attacker need an account?
- No. GitLab says an unauthenticated user could execute code under certain conditions.
- Is it being exploited?
- GitLab's release notes do not report exploitation, but it has published detections to help spot attempts.
VulnerabilitySecurity UpdatePatch ManagementApplication SecurityCI/CD SecurityRemote Code ExecutionGitLab