GitLab CVE-2026-110264: A CVSS 10 Flaw, and Why Patching on 12 October Was Not Enough

If you patched GitLab on 12 October, you did the right thing, and you are exposed again. On 21 October GitLab released fixes for CVE-2026-110264, rated 10.0, which could let an unauthenticated attacker run code on a self-managed GitLab server under certain conditions. The flaw is in Onigmo, the regular-expression engine built into Ruby, and it reaches back to GitLab 7.0 from 2014. Romania's DNSC and Belgium's CCB have both issued alerts about it, and the CCB's tells organisations to patch immediately.

There are no reports of exploitation yet. That is the good news and the reason to act now: a server that runs your CI/CD is also one of the largest secret stores most organisations have.

What is confirmed

According to The Hacker News and the CVE record, the flaw is an integer overflow while compiling a specially crafted regular expression, in the copy of Onigmo that GitLab ships and patches in its own packages. Every release back to 7.0 is affected. The fixed versions are 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13, the last of which covers the 7.0 to 18.11 range; several were backported outside GitLab's normal schedule. GitLab.com already runs a fixed version, and Dedicated tenants on the stated internal builds already have the fix. GitLab says there is no interim workaround.

The catch is the earlier fix. The 12 October release, which fixed a related flaw tracked as CVE-2026-97229, covered only 19.2 and later, and the 21 October releases sit one patch above it. An instance updated on 12 October is therefore vulnerable to the new flaw. The Hacker News reports that four critical GitLab flaws over the past month trace back to Onigmo bugs, and that Ruby has released 4.0.9, 3.4.12 and 3.3.13 to fix them in the language itself.

Note on upgrades: single-node upgrades to 19.4.3 and 19.3.6 run database migrations and need downtime, while multi-node installations can use GitLab's zero-downtime procedure. Plan the window rather than postponing it.

What is not known

Exploitation. GitLab reports no sign of it, there is no public proof of concept in the reporting we read, and the flaw was not on CISA's known-exploited list as of 22 October. That can change quickly once a patch can be compared with the code it fixes.
The “certain conditions”. GitLab has not published what a request needs to look like, which is deliberate, and means you cannot reason your way out of patching.
The exact version boundaries for your install. Third-party summaries differ on details. Take the fixed version for your line from GitLab's advisory and your package manager.

What a GitLab server holds

Code execution on GitLab is code execution on the system that runs your pipelines. What it can reach depends on your setup, but typically includes CI/CD variables with cloud and registry credentials, runner tokens, deploy keys and tokens, personal, project and group access tokens, OAuth application secrets, webhook secrets, and the server's own configuration with directory, mail and database credentials. On Omnibus installations, the keys that encrypt CI/CD variables sit on the same server, so encrypted variables are only as safe as the host.

That is why, if this flaw is ever used against your instance, the cleanup is a rotation of everything above. It is also why patching before anyone tries is so much cheaper.

What to do

Upgrade every self-managed instance now, including the ones you patched on 12 October, test and staging instances, and old installations you thought were retired.
Turn on detection. GitLab has published two detection rules for this issue, for a crash of the Onigmo native worker and a burst of org-mode rendering errors. Use them, and keep the logs.
Restrict exposure while you schedule the upgrade. If an instance does not need to be on the internet, put it behind a VPN or allow-list.
Prepare the rotation list before you need it. Inventory where your CI/CD variables, runner tokens, deploy keys and access tokens are defined, and who owns each. If a detection rule ever fires, you will want that list in hand.
Prefer credentials that expire. Replace long-lived cloud keys in CI variables with short-lived federated identity, and set expiry dates on access tokens, so that a compromise of GitLab yields less.
Check your own Ruby applications. Per The Hacker News, any Ruby application that builds a regular expression from attacker-controlled text is exposed to the same engine bugs, not just GitLab. Upgrade Ruby, and stop compiling regular expressions from untrusted input where you can.

The handover after a rotation

If you do have to rotate, new tokens and keys go to project owners and the engineers who configure pipelines. Do not put them in an issue, a merge request or the incident channel on the same GitLab instance. Send each value once, to the one person who needs it, over a channel that does not keep it.

Where Secretus fits, and where it does not

Secretus covers that handover: a person encrypts a short text secret in the browser and shares a link that stops working after the expiry they set or the first successful open. Team Split can require several holders to reconstruct a high-value text secret.

It is not a GitLab tool or a secrets manager. It cannot patch GitLab, scan pipelines, rotate a runner token or tell you whether your server was targeted. Use GitLab's guidance for that, and a one-time link for the moment one person gives another a new credential.