Sunday, 25 October 2026Global tech news & guides — what changed, and what it means for you.
AuTechWire
Illustration: a dark server room with a terminal screen cracked open, red warning light spilling out as a padlock shatters into code fragments

Patched GitLab on October 12? Patch It Again — CVE-2026-110264 Is a CVSS 10.0 Flaw

by

In brief

Last checked October 24, 2026: GitLab reports no in-the-wild exploitation; CVE-2026-110264 is not in CISA’s Known Exploited Vulnerabilities catalog.

  • On October 21, 2026, GitLab released emergency patches for CVE-2026-110264, a vulnerability rated the maximum 10.0 on the CVSS scale. Under certain conditions, an attacker with no account can run arbitrary code on a self-managed GitLab server. Every release from GitLab 7.0 (2014) through 19.5 is affected.
  • If you patched GitLab on October 12, you are still exposed. That release fixed a different flaw (CVE-2026-97229). The new fixed versions sit one patch above it, so an instance updated then is vulnerable again. You must patch a second time.
  • Fixed versions: 19.5.1, 19.4.3, and 19.3.6 (all 12 fixes in this release), plus backports to 19.2.9, 19.1.9, 19.0.10, and 18.11.13 (critical fix only). If you run 18.10 or older, no patch exists — you must upgrade to a supported line.
  • GitLab says it has seen no sign of the flaw being used in attacks, and as of October 22 it is not in the U.S. CISA catalog of known exploited vulnerabilities. But the company has not said what conditions an attacker needs to reach the flaw — so you cannot rule yourself out by configuration. The patch is the only certain protection, and there is no workaround.

Are you affected? The decision matrix

Only self-managed GitLab needs action. Find the row that describes you:

You run your own GitLab server (Linux package, Docker, Helm chart, or source install, Community or Enterprise Edition) — act now. Every version from 7.0 is affected, and GitLab offers no workaround. Upgrade to the fixed version for your release line today.

You patched GitLab on October 12 (you’re running 19.4.2, 19.3.5, or 19.2.8) — act now. You are still affected. The October 12 release fixed an earlier regex flaw; this one needs the next patch up: 19.4.3, 19.3.6, or 19.2.9. This is the single most important fact of this story, and it’s the one most likely to be missed.

You run GitLab 18.10 or older — act now. No fixed release exists for your line. Upgrade to 18.11.13 or later, which may take several steps. GitLab’s normal patch policy covers only the current release and the previous two monthly releases; it backported this fix to four older lines purely on severity, but lines older than 18.11 got nothing.

You use GitLab.com — you’re protected. Nothing to do; GitLab.com already runs the fixed version.

You use GitLab Dedicated — you’re protected. Tenants on 19.3.5-internal0, 19.4.2-internal0, or later already have the fixes.

The fix table

Stay on the minor version you run — a patch upgrade (for example, 19.4.x to 19.4.3) needs no extra upgrade stops.

If you run Upgrade to What it fixes
19.5 before 19.5.1 19.5.1 All 12 fixes
19.4 before 19.4.3 19.4.3 All 12 fixes — includes database migrations
19.3 before 19.3.6 19.3.6 All 12 fixes — includes database migrations
19.2 before 19.2.9 19.2.9 Critical fix only
19.1 before 19.1.9 19.1.9 Critical fix only
19.0 before 19.0.10 19.0.10 Critical fix only
7.0 through 18.11, before 18.11.13 18.11.13 Critical fix only
18.10 and older No fixed release Upgrade to a supported line

Two things to note about that table. First, the backport releases (19.2.9, 19.1.9, 19.0.10, 18.11.13) carry only the critical fix — the other 11 flaws in this release, including two rated high, are fixed only in 19.3.6, 19.4.3, and 19.5.1. If you can move to a newer line, do it; the backports are a bandage, not the full treatment.

Second, 19.4.3 and 19.3.6 include database migrations that run during the upgrade. On a single-node server, that means downtime while they finish. Multi-node installations can apply the patch without downtime using GitLab’s zero-downtime upgrade procedure — worth planning before you start, not after.

How to check your version

Run the command for your install type, or open the /help page while signed in:

Linux package: sudo cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

Docker: docker exec <container> cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

Helm chart: helm list --all-namespaces | grep -i gitlab — read the APP VERSION column, not the chart version. If you set global.gitlabVersion, that value wins.

API (any install): curl --header "PRIVATE-TOKEN: <your-token>" "https://gitlab.example.com/api/v4/version"

And list every GitLab server you run — including Geo secondaries (read-only replicas), staging, disaster recovery, and test instances. A forgotten instance is still a way in.

What the flaw actually is

The root cause is in Onigmo, the regular-expression engine built into Ruby, which GitLab ships inside its own packages. When that engine compiles a specially crafted regular expression, an integer overflows. Because the overflow is in the engine itself, the flaw reaches back to GitLab 7.0, released in 2014 — a weakness in a shared component is present wherever GitLab shipped it, which is everywhere.

The attack path comes from GitLab’s own detection rule, published the same evening as the patch. GitLab renders Org mode files (a plain-text document format it displays like Markdown) using a gem called org-ruby. That gem takes the keyword from a #+TODO: line of a .org file and builds a regular expression out of it — without escaping it. A keyword with more than 32,767 repeats overflows a counter in the regex engine, which then writes outside its own memory when the expression runs. GitLab says that can be turned into code execution running as the git user.

The uncomfortable part: the rule says the attack needs no login. It needs only one public project holding the crafted .org file for GitLab to render. And a successful attempt can be quiet — it doesn’t reliably crash the server.

Why this keeps happening

This is the fourth code-execution flaw in GitLab’s regular-expression engine reported by the same researcher in a single month. The researcher, who uses the handle joaxcar, reported through GitLab’s HackerOne bug bounty program:

  • September 23, 2026: CVE-2026-93577 and CVE-2026-89078 — two regex-engine code execution flaws rated 9.9, but requiring a logged-in account.
  • October 12, 2026: CVE-2026-97229 — CVSS 10.0, a similar overflow reached through CI/CD configuration, affecting versions 19.2 through 19.4.
  • October 21, 2026: CVE-2026-110264 — CVSS 10.0, the Org-mode path described above, affecting every version since 7.0.

The pattern is clear: someone is systematically auditing the attack surface of GitLab’s regex engine, and each pass reaches further. The October 12 flaw stopped at version 19.2; this one does not. Expect the fifth. If you self-host GitLab, patching promptly is no longer optional — it’s the operating rhythm.

What else is in this release

The October 21 release fixes 11 other security issues — one critical (this one) and the rest high, medium, or low. Two are worth knowing about:

  • CVE-2026-15723 (high, 8.2): a logged-in user could take over another account, but only when an administrator has enabled both SAML and LDAP auto-linking. Affects every version since 10.1.
  • CVE-2026-112212 (high, 7.5): a cache-poisoning flaw in GitLab’s OAuth and OpenID Connect endpoints could let an attacker redirect certain sign-in flows to a server they control, in setups that use a shared cache. Affects versions since 18.3.

Remember: these eleven are fixed only in 19.3.6, 19.4.3, and 19.5.1 — the older backport releases carry just the critical fix.

How to look for exploitation attempts

GitLab published two detection rules for CVE-2026-110264 in its open-source TLDR framework, written in the Sigma format so they convert to the query language of most log-monitoring tools:

  • “Org mode render error burst”: one client causing five or more Org mode render timeouts within 30 minutes, recorded in exceptions_json.log.
  • “Onigmo native worker crash”: a GitLab worker crashing inside the regular expression engine, recorded in puma_stderr.log.

The rule documentation also gives a check for planted payloads: look for oversized #+TODO: lines in .org files — run it in each checkout of any suspect repository:

rg -l --glob '**/*.org' '^\#\+(TODO|SEQ_TODO|TYP_TODO):.{500,}'

A crash is a reason to investigate, not proof of compromise. If you find signs of a successful attack, treat the server as compromised: code would run as the account GitLab itself runs as, so rotate CI/CD variables, runner tokens, deploy keys, and access tokens held on it. One caveat: many instances don’t ship puma_stderr.log or the Workhorse log by default — check each rule’s own page for the log sources and fields it needs before relying on it.

For compliance teams: GitLab holds your source code and often your deployment secrets, so auditors will expect a dated record of this patch. Record each GitLab instance, its version before and after, and the upgrade date (ISO 27001:2022 A.8.8). GitLab makes its internal issue reports public 90 days after the fix, so full technical details are expected around January 2027.

What to do today

  1. Inventory every GitLab instance you run — production, Geo secondaries, staging, DR, test. The forgotten one is the way in.
  2. Check each version with the commands above.
  3. Install the fixed patch for your line from the fix table. Single-node servers on 19.3.x or 19.4.x should plan for migration downtime; multi-node setups can use the zero-downtime procedure.
  4. If you’re on 19.2 or older, the backport buys you the critical fix today — but plan a move to 19.3.6 or later for the other 11 fixes.
  5. Run GitLab’s two detection rules over recent logs, and check suspect repositories for oversized #+TODO: lines.
  6. If a rule fires and the signs point to success, treat the server as compromised and rotate every credential it holds — CI/CD variables, runner tokens, deploy keys, access tokens.

The trap to avoid: feeling safe because you patched nine days ago. The October 12 patch closed one door; this flaw opens a wider one. Patch again.

Sources

Shoaib Hassan

Shoaib Hassan is the founder and editor of AuTechWire, an independent technology publication covering broadband, mobile networks, privacy, startups, and consumer tech.

Related Stories

Leave a Comment