SURIQ
GitLab has now patched two maximum-severity remote code execution (RCE) flaws in its regular-expression handling inside ten days. The first, CVE-2026-97229, landed on October 12. The second, CVE-2026-110264, shipped on October 21 with a CVSS score of 10.0, and it has a far bigger blast radius: the vulnerable code reaches back to GitLab 7.0, released in 2014. If you self-host GitLab, the fix you applied last week does not close this one.
Both are integer overflows in a regular-expression compiler, which is becoming a recurring soft spot in this product. The practical consequence is the same and it is severe. According to GitLab's advisory, a remote attacker holding no account could, in the right conditions, push the server into compiling a hostile regular-expression pattern and execute code through the overflow it causes. There is no login step, no user interaction, and the attack complexity is low, which is how it lands at a flat 10.0 on the severity scale.
A deeper flaw than last week's
The bug sits in Onigmo, the regex library that ships inside the Ruby runtime GitLab runs on. Public reporting from SOC Prime points to GitLab's rendering of Org mode, a plain-text markup format, as the likely path into the flawed compiler, though GitLab has deliberately held back the precise trigger while operators patch. The flaw was reported privately through HackerOne by a researcher credited as joaxcar, and GitLab's managed infrastructure, GitLab.com and GitLab Dedicated, was already fixed before disclosure.
The Dutch national cyber agency NCSC-NL rated the release medium-to-high overall, with this single flaw marked critical. The fixed versions span seven release branches.
| Release branch | Fixed version |
|---|---|
| 7.0 through 18.11 | 18.11.13 |
| 19.0 | 19.0.10 |
| 19.1 | 19.1.9 |
| 19.2 | 19.2.9 |
| 19.3 | 19.3.6 |
| 19.4 | 19.4.3 |
| 19.5 | 19.5.1 |
Why the October 12 patch does not protect you
This is the detail an advisory summary will not flag for you. The October 12 release that fixed CVE-2026-97229 shipped as 19.4.2, 19.3.5, and 19.2.8. CVE-2026-110264 is fixed in 19.4.3, 19.3.6, and 19.2.9. A server you upgraded to 19.3.5 last week to close the first regex RCE is still exposed to the second. Patching is not a one-time event here. You need the October 21 build, and you need to confirm the running version on every host rather than assume last week's upgrade carried over.
The scope is the other trap. Because the weakness has existed since 2014, there is no "we are on an old, stable release, so we are fine" position. Every self-managed GitLab older than the October 21 patch, across twelve years of releases, is in range. We have covered unauthenticated file-read and session-hijack flaws in GitLab before, but a no-login path to code execution that spans the entire version history is a different order of risk.
No public exploit yet. That is exactly when to hunt.
As of publication, neither GitLab nor the researchers who have written about the flaw report in-the-wild exploitation, and SOC Prime states no public proof-of-concept exploit has been disclosed. Repositories named after the CVE have appeared on GitHub, but the ones we reviewed are exposure scanners and auditors, not working exploit code. GitLab has withheld the attack path precisely to buy defenders time, so the realistic clock is the days it takes for someone to reverse-engineer the fix.
That gap is the window to look backward, not just forward. Patching closes the hole; it does not tell you whether anyone walked through it first. GitLab published two detections specifically for this flaw, and a self-managed operator should enable them and then search historical logs for the same signals. This is the patch-is-not-the-finish-line discipline applied to a concrete case.
GitLab-published threat detections to enable and search for: - "Onigmo native worker crash" - "Org mode render error burst" Host and log signals worth reviewing after patching: - repeated crashes of GitLab Ruby, Puma, or Sidekiq worker processes - bursts of Org mode rendering errors in production and application logs - unexpected child processes or shell execution spawned by GitLab or Ruby - new outbound network connections originating from the GitLab server - new SSH keys, accounts, tokens, or repository changes you did not make
A compromised GitLab server is a supply-chain problem, not just one more breached host: it can hold source code, deployment credentials, and continuous integration pipelines that push to production. Validate repository and pipeline integrity before you call the incident closed.
What self-managed operators should do now
Upgrade to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, or 18.11.13, matching your branch, and verify the version on each host after the upgrade. If you cannot patch within the day, put the web interface behind a VPN or an IP allowlist to shrink the unauthenticated attack surface while you schedule the work. Then run the retrospective hunt above, because an internet-facing instance that sat unpatched should be treated as reachable until the logs say otherwise.
The same October 21 release fixed two more authentication flaws worth noting while you are upgrading: CVE-2026-112212 (CVSS 7.5), a cache-poisoning issue in OAuth and OpenID Connect discovery endpoints that could redirect certain login flows to an attacker-controlled server, and CVE-2026-15723 (CVSS 8.2), an account-takeover path that appears when both OmniAuth SAML and LDAP auto-linking are enabled. One upgrade clears all three.