On October 21, GitLab shipped patches for CVE-2026-110264, an unauthenticated remote code execution bug with a CVSS score of 10.0. That's the maximum. The cause is an integer overflow while compiling a specially crafted regular expression, inside the Onigmo regex engine that GitLab bundles. Every self-managed release from 7.0 (2014) onward is affected.
GitLab says it has no evidence of exploitation, and as of October 22 the bug wasn't in CISA's Known Exploited Vulnerabilities catalog. GitLab.com is already on a fixed version. If you run your own instance, you have homework.
The patch list is the easy part
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 (which covers everything from 7.0 through 18.11). There's no interim workaround in the advisory. You upgrade or you stay exposed.
Two things to plan for before you start:
- The 19.4.3 and 19.3.6 releases include database changes. On a single-node server that means downtime, so schedule it. Multi-node setups can use GitLab's zero-downtime procedure.
- GitLab published two detection rules in its TLDR framework, "Onigmo native worker crash" and "Org mode render error burst". Run them against your logs. A crafted regex that doesn't quite work the first time tends to leave crashes behind.
Another report this month described exploitation attempts against an Atlassian Data Center flaw within two hours of public details. "No evidence of exploitation" has a short shelf life once a CVSS 10 is public.
Why this one stings more than a typical RCE
Think about what lives on your self-hosted GitLab. Your entire source history. Deploy tokens. CI/CD variables with cloud credentials. Container registry images. Runner access into your build network. Whoever gets code execution there doesn't need to hunt for a foothold. They're already standing in the room where everything is made.
Yet most teams run their Git server like a utility. It was set up years ago, it's behind the VPN (maybe), upgrades happen when someone remembers, and nobody's on call for it. We've seen instances sitting three or four minor versions behind because "it works and nobody wants to break CI."
I'd argue the Git server and CI system belong in the same tier as your production database. If it can push code to prod, it is prod.
What we'd do this week
Patch first, then fix the habits that made patching painful.
- Upgrade to a fixed version and confirm the version in the admin panel, not just in the change ticket.
- Rotate secrets that your CI holds if you can't rule out exposure. It's annoying. It's cheaper than finding out later.
- Check whether the instance is reachable from the public internet. If it doesn't need to be, it shouldn't be.
- Put the instance on a patch cadence with an owner. A named person, not a team alias.
- Inventory what else bundles regex engines and parsers you've never looked at. A twelve-year-old bug in a vendored library is a reminder that your dependency tree includes the tools you build with, not only the code you ship.
The takeaway
Nobody chose to have a 12-year-old vulnerability. It accumulated quietly in a component nobody reviews. The fix is boring, and so is the prevention: treat your build and source infrastructure with the same care you give customer-facing systems, because attackers already do.
We're here to help founders and teams design and build digital products that are built to scale with you, not slow you down. If you're looking to build something, get in contact with us today!