## What happened?
The vulnerability is identified as CVE-2026-110264 and has a CVSS score of 10.0: it can be exploited remotely, without an account and without user interaction, with a total impact on the server’s confidentiality, integrity and availability.
The issue stems from Onigmo, Ruby’s regular expression engine, which GitLab embeds in its own packages. A specially crafted regular expression causes an integer overflow during compilation. This memory overflow can then be exploited to execute arbitrary code on the server.
The vulnerability was reported by the researcher joaxcar via GitLab’s bug bounty programme. This is his fourth code-execution vulnerability in this engine in around a month. But this is the first one to date back that far: GitLab 7.0, released in 2014.
Important note: the 12 October patch (CVE-2026-97229) only covered versions 19.2 and later. An instance updated on 12 October remains vulnerable until it has been upgraded to the new versions.
# Who is affected?
All self-hosted GitLab instances (Community and Enterprise Edition), installed via Omnibus packages or container images, are affected. If you use GitLab.com, you do not need to take any action: the platform has already been patched, as have GitLab Dedicated instances.
Fixed versions
- 19.5.1
- 19.4.3
- 19.3.6
- 19.2.9
- 19.1.9
- 19.0.10
- 18.11.13
GitLab has made an exception to its usual policy by backporting the fix as far back as the 18.11 branch. If your instance is even older, you must upgrade to at least version 18.11.13.
To date, GitLab has not reported any active exploitation, and the vulnerability does not appear in CISA’s KEV catalogue. However, no workaround is available: updating is the only protection.
#Why this is a serious matter
A GitLab server is not like any other server. It often contains a company’s entire software assets, along with the keys required to deploy them. An attacker who gains control of it can:
• steal the source code and the intellectual property it contains;
• retrieve secrets stored in CI/CD variables: API keys, cloud access credentials, database passwords;
• modify the code or pipelines to slip a backdoor into applications delivered to customers;
• jump to production servers and the rest of the network.
The same patch also addresses eleven other vulnerabilities, including two high-severity ones: an account takeover vulnerability when SAML and LDAP self-linking are enabled (CVE-2026-15723, 8.2), and a cache poisoning vulnerability on OAuth/OIDC endpoints (CVE-2026-112212, 7.5).
# What should you do now?
1. Identify all your GitLab instances, including test servers, forgotten instances and associated runners.
2. Check the version (Help menu or /help) and compare it with the table above.
3. Update to the patched version for your branch. Start with instances exposed to the internet.
4. Allow for a brief interruption: versions 19.4.3 and 19.3.6 contain database migrations. On a single-server setup, GitLab will be unavailable whilst the update is taking place; multi-node installations can carry out the procedure without any downtime.
5. Do not rely on the 12 October patch: it does not protect against this new vulnerability.
6. Check for signs of an attack. GitLab has published two detection rules (‘Onigmo native worker crash’ and ‘Org mode render error burst’) to apply to application logs.
7. If in doubt, change your secrets: access tokens, CI/CD variables, and SSH deployment keys.
# In summary
A 10/10 vulnerability, requiring no authentication, affecting all self-hosted versions since 2014, with no possible workaround: you must update immediately. Two critical vulnerabilities in ten days affecting the same component also demonstrate that a self-hosted GitLab requires updates to be monitored just as regularly as a production server.
Do you host your own GitLab and aren’t sure if you’re up to date? Our team can check your instances, apply the patch and verify that they haven’t been compromised. Tell us about your situation.
