GitLab Patched a CVSS 10. The Bug Was Ruby’s Regex Engine.

There’s nothing to switch off. No feature flag, no allowlist, no setting a careful administrator could have got right.

That’s what a 10.0 in a framework bug looks like from the operator chair. The vulnerable code is a regex compiler that has shipped inside Onigmo for years, and GitLab inherited it the way every Ruby application inherits it, by calling Regexp.new on text it did not write.

The overflow happens in a compiler, before any match runs

Onigmo keeps two kinds of identifier in a signed 16-bit bytecode field. One marks a range repeat, the other marks a null check. The compiler counts upward in an ordinary int. Past 32,767 of either in a single pattern, the identifier wraps negative, and the negative value is what gets emitted.

GitLab’s description of the backport says it plainly. Onigmo stores range-repeat and null-check IDs in a signed 16-bit bytecode operand but counts them in an int, so a regexp with more than 32,767 of either wraps the ID negative. At match time that negative index reads the repeat stack backwards, past the start of the array, and the engine writes there.

The attacker needs no GitLab feature. They need one endpoint that compiles a caller-supplied pattern, and a code host has dozens, because search, rendering and diffing all ask a regex engine what a stranger’s text is.

There’s no mitigation to write down. The compiler now refuses the pattern outright, raising RegexpError about too many range repeats or too many null checks.

GitLab backports the fix because Ruby hasn’t shipped it

The fix landed upstream on Ruby master only, which means 4.1. It isn’t on the 3.3, 3.4 or 4.0 branches, so the Ruby lines GitLab builds against are still vulnerable on their own release trains. GitLab carries three variants of the patch in its omnibus and container images, one per line, and applies them at build time.

This is the second patch of that shape sitting in the same build. A program-size overflow in the same compiler was already being handled the same way, which tells you who absorbs the risk when a runtime lags its own security fix. The answer is the vendor downstream of it. If you run GitLab’s official images, the patch arrives with the image. If you build your own Ruby, or you run a distribution package, you own a compiler CVE now.

Upgrade tonight, then read the detections

GitLab CVE-2026-110264 is fixed in seven releases. The patch release notes backport the fix to 18.11.13, 19.0.10, 19.1.9 and 19.2.9 on top of the regular 19.3.6, 19.4.3 and 19.5.1 releases. The affected range starts at 7.0. That isn’t a typo. It’s the whole product line.

GitLab.com is already patched. GitLab Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 and later have the fixes. Everyone self-managed is the exposure, which is the part of the customer base most likely to sit on the public internet. The CVE record carries the full vector.

Single node installs take downtime, because 19.3.6 and 19.4.3 include migrations. Multi-node installs can use the zero downtime path. Follow the documented order rather than improvising at 11pm.

The same release carries two more flaws worth reading. An OmniAuth and LDAP auto-linking bug at 8.2 lets an authenticated user take over an LDAP-backed account with no interaction from the target. A cache poisoning flaw in OAuth and OIDC discovery sits at 7.5 and can redirect flows to a server the attacker controls.

Then use what GitLab published with the release. It shipped two detection rules for self-managed instances, an Onigmo native worker crash and an org mode render error burst. A worker that dies compiling a regex, or a burst of render errors, is worth an hour of log reading on any instance that has been internet-facing.

Three questions for your own environment. Which endpoints compile a pattern a stranger can influence? How long has your current version been internet-facing? And if a worker crashed last month, would anyone have noticed?

The same week, a much smaller project shipped a credential stealer to PyPI in the LiteLLM 1.107.0 supply chain attack, and the lesson there was the release path. Here the lesson sits one layer lower. You inherit the memory safety of every runtime you ship, and you inherit its bugs on the runtime schedule, not yours.