If you run self-managed GitLab, October gave you two emergency upgrades in nine days. If you only did the first one, you're still exposed.

Both fixes address maximum-severity, unauthenticated remote code execution. Both trace back to the same weak spot: how GitLab, and the Ruby regex engine underneath it, handle attacker-controlled regular expressions.

The three bugs

CVE Severity Entry point Fixed Status
CVE-2026-93577 9.9 CI/CD regex handling 23 Sep 2026 patched (bypassed by the next one)
CVE-2026-97229 10.0 CI/CD regular-expression compiler 12 Oct 2026 (19.4.2, 19.3.5, 19.2.8) exploited, in CISA KEV since 29 Oct
CVE-2026-110264 10.0 Rendering a crafted .org file 21 Oct 2026 (19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13) no confirmed exploitation as of late Oct

All three were reported by the same researcher, joaxcar, through HackerOne. GitLab.com and GitLab Dedicated weren't affected by CVE-2026-110264. This is a self-managed problem.

CVE-2026-97229: now exploited

On 29 October 2026, CISA added CVE-2026-97229 to its Known Exploited Vulnerabilities catalog. BleepingComputer reports it's an integer overflow in GitLab's CI/CD regular-expression compiler, caused by insufficient validation. Under certain conditions, an unauthenticated attacker can trigger it with a crafted regex in CI/CD configuration and run code on the server.

GitLab says it has seen exploitation attempts and has published detections for self-managed customers. Shadowserver tracks around 2,800 internet-exposed GitLab Community Edition instances, though it isn't clear how many are already patched.

CVE-2026-110264: patched, not yet known to be exploited

Nine days later came a second CVSS 10.0, and this one goes back a long way. It affects every self-managed CE and EE release since 7.0, which shipped in 2014.

According to an analysis published on 22 October, the path runs through Org-mode rendering:

crafted .org file in a (public) repository └─ GitLab renders it with the org-ruby gem └─ #+TODO: keywords passed to Regexp.new without escaping └─ Onigmo (Ruby's regex engine) compiles the pattern └─ repeat counter stored as signed 16-bit → wraps past 32,767 └─ out-of-bounds write → code execution on the server

Simplified for understanding. Not a reproduction guide.

Two details matter for admins:

  • The 12 October patch doesn't fix this one. If you upgraded for CVE-2026-97229 and stopped there, you need the 21 October versions too.
  • There's no workaround. No setting turns off only Org-mode rendering, so upgrading is the fix. Versions 18.10 and older have to step through GitLab's required upgrade stops to 18.11.13 or later.

Why regex keeps biting

Regular expressions look like strings, but compiling one runs a small program inside a C engine. When an application lets untrusted input become a regex (a CI rule, a TODO keyword, a search filter), the engine's own memory-safety bugs become reachable from the internet.

That's why Ruby itself shipped fixes. The Onigmo fix was merged to Ruby's main branch in April but hadn't reached the stable branches, and Ruby 4.0.9, 3.4.12 and 3.3.13 now include it. GitLab Omnibus bundles its own patched Ruby. Installs that run GitLab from source on the system Ruby need to update Ruby separately.

Who is affected

  • Self-managed GitLab CE/EE that isn't on the 21 October releases. That's anyone on the 12 October versions, and anyone further behind.
  • Instances with public projects or open sign-up. The .org path needs a repository the attacker can write to or create.
  • Source installs on system Ruby, until Ruby is updated.
  • Other Ruby apps that pass user input to Regexp.new should take the Ruby updates seriously too.

GitLab servers are high-value targets. They hold source code, CI/CD variables, deploy keys and runner tokens, so one compromised instance can reach your entire delivery pipeline.

What to do 

# Check your version (Omnibus) sudo gitlab-rake gitlab:env:info | grep -i "GitLab information" -A2 # Detection ideas from GitLab's published rules: # - repeated Timeout::Error bursts around Org-mode rendering in exceptions_json.log # - "[BUG]" native crash reports from the regex engine in puma_stderr.log sudo grep -c "\[BUG\]" /var/log/gitlab/puma/puma_stderr.log
  1. Upgrade to the 21 October releases (19.5.1 / 19.4.3 / 19.3.6 / 19.2.9 / 19.1.9 / 19.0.10 / 18.11.13) or later.
  2. If you were exposed while unpatched, assume CI/CD secrets may be compromised. Rotate CI variables, deploy keys, runner registration tokens and personal access tokens.
  3. Check logs using the detections above. A successful attack may leave no trace, so absent logs don't prove you're clean.
  4. Reduce exposure: restrict sign-ups, review public projects, and put self-managed GitLab behind SSO or a VPN where you can.
  5. Source installs: update system Ruby to a fixed release.

What might happen next (analysis)

This section is analysis, not reporting.

Three critical regex RCEs from one researcher in a month suggests the shared root cause has been found and is now being mined. Expect more findings in other Ruby applications and gems that build regexes from user input. CVE-2026-110264 may not stay unexploited for long: its predecessor reached KEV within weeks of its patch, and the affected range goes back to 2014. Expect more scrutiny of "render this file format" features too, which tend to be old, rarely reviewed and reachable without authentication.

Conclusion

GitLab's month is a good reminder that "we patched the critical one" isn't a state, it's an event. A follow-up bug may need a second upgrade. If you run self-managed GitLab, check you're on the 21 October releases today, and treat your CI secrets as part of the blast radius.

Your turn: how long does it take your team to apply an out-of-band GitLab or CI-server patch, and who decides?

References

Part of The Wire, a daily brief on the tech and security news that matters to developers. Details are as reported up to 31 October 2026.

☕ Enjoyed this post? You can support my writing on Ko-fi.

Support me on Ko-fi