Hossam EL-Kashef

The Horizon

Your self-managed GitLab server needs a patch today

22 October 2026 · Hossam EL-Kashef

Third security post in a week. I’d prefer to write about something else, but this one matters for a lot of engineering teams.

On October 21 GitLab shipped a critical patch release. The headline bug is CVE-2026-110264, rated 10.0, the maximum score. Under certain conditions, someone without an account can run code on a self-managed GitLab server. And it goes back to GitLab 7.0. That’s roughly twelve years of releases.

What it is, in plain words

GitLab uses Onigmo, the regular expression engine that comes with Ruby. When that engine compiles a specially crafted regex, a number overflows. GitLab says that can let an unauthenticated attacker run code on the server. GitLab’s detection rule gives a hint: the trigger is a crafted .org file in a public project, and code runs as the git user. The full issue usually goes public 90 days after the fix, so around January.

Why this is a big deal: your GitLab server isn’t just a git host. It has your source code, your CI variables, your deploy keys, runner tokens, often cloud credentials. Somebody running code on that box can reach basically everything you ship. It’s the same lesson as secrets being the new target, just from a different door.

Who is affected

  • Self-managed GitLab, both CE and EE, every version from 7.0 up to the fixed releases below.
  • GitLab.com and GitLab Dedicated are already patched. If you’re only on GitLab.com, this one isn’t yours to fix.
  • No public exploit code and no reported attacks yet, and it wasn’t in CISA’s Known Exploited Vulnerabilities list as of October 22. That’s the good news. After the PHP bugs this week, I wouldn’t wait for one.

The fixed versions:

  • 19.5.1
  • 19.4.3
  • 19.3.6
  • 19.2.9
  • 19.1.9
  • 19.0.10
  • 18.11.13

If you’re on 18.10 or older, there’s no fixed release for your line. You have to upgrade to 18.11.13 or later, which may take several steps. GitLab’s upgrade path tool shows the route.

One more thing that’s easy to miss. GitLab fixed a different 10.0 regex bug on October 12 (CVE-2026-97229). If you patched then, you are not covered for this one. Different bug, new versions.

The release also fixes 11 other issues, including a high-severity OmniAuth-to-LDAP account takeover (CVSS 8.2) and an OAuth/OIDC discovery cache poisoning bug (CVSS 7.5). Those are only fixed in 19.3.6, 19.4.3 and 19.5.1. The older backports carry just the critical fix, so being on 19.5.1 is the better place to be.

What I’d do today

1. Find every self-managed GitLab. The main one is easy. The old instance a team kept “just for the archive”, the one inside a customer environment, the test server someone set up two years ago. Those are the ones that don’t get patched.

2. Patch the internet-facing ones first. There’s no official workaround, so upgrading is the fix. GitLab’s detection rule suggests reducing public project visibility in the meantime, which narrows the attack but doesn’t close it. Check the release notes before you start: 19.4.3 and 19.3.6 include database migrations that mean downtime on single-node installs. Multi-node setups can do a zero-downtime upgrade. Tell people, take the downtime, move on.

3. If you can’t patch today, shrink who can reach it. Put it behind your VPN or restrict access by IP until the upgrade is done. That’s not a fix, it’s buying time.

4. Check for signs anyway. GitLab published two detection rules: “Onigmo native worker crash” and “Org mode render error burst”. If you see bursts of those in your logs, or new admin users, new SSH keys, new personal access tokens you can’t explain, treat it as an incident.

5. If anything looks off, rotate. CI/CD variables, deploy tokens, runner registration tokens, and any cloud keys stored in GitLab. Assume what was on the box is out.

The bigger point

Three security problems in a week, all in things that sit in the middle of how we build software: a deploy platform, a programming language a lot of the web runs on, and now the system holding our code. Patching isn’t the hard part. Knowing what you run, where, and who owns it is. If finding all your GitLab servers takes more than ten minutes, that’s the real thing to fix this quarter.

Sources