CVE-2026-110264Is your GitLab affected?

npx wardlatch@latest --incident gitlab-2026-10

It reads the installed version from GitLab’s own version files and never runs GitLab: /opt/gitlab/version-manifest.txt and /opt/gitlab/embedded/service/gitlab-rails/VERSION for the Linux package, and /home/git/gitlab/VERSION for an install from source. It compares that with the fix for its line and says EXPOSED (with the fix), SAFE, or UNKNOWN when a file couldn’t be read. It changes nothing and sends nothing.

By hand: this reads two of those files, the two VERSION files, and prints the version in each, with the file’s name in front.

grep -H . /opt/gitlab/embedded/service/gitlab-rails/VERSION /home/git/gitlab/VERSION

Fixed

19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13, or later on the same line.

Upgrade

An earlier version on one of those lines.

No patch

18.10 or older: upgrade to a supported line.

From source

A line from /home/git/gitlab/VERSION on a fixed version: GitLab’s fix also patches the regular-expression engine of Ruby (Onigmo), which the Linux package carries itself and an install from source takes from its own Ruby. Check that your Ruby has GitLab’s patch (section C).

No such file

“No such file or directory” for a file: no GitLab installed that way. For both: no GitLab in those two places. GitLab in Docker or Kubernetes isn’t there; check its version the way you deployed it.

Permission denied

The command couldn’t look in that file, so it says nothing about the version: run it again with sudo in front.

• GitLab.com is already running the fix, GitLab says. GitLab Dedicated tenants running 19.3.5-internal0 or 19.4.2-internal0 or later already have it and need do nothing.
• 18.10 and older get no patch: upgrade to a supported line.
• Every way of installing is affected where GitLab doesn’t name one, its patch page says, so that includes containers and Helm charts.

1. Upgrade GitLab to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13, or later on your line. GitLab strongly recommends upgrading immediately, and gives no workaround.
2. Read the upgrade notes on GitLab’s patch page before you start: these releases include database migrations, a single-node server has downtime during the upgrade, and a multi-node one can follow GitLab’s zero-downtime procedure.
3. On 18.10 or older, upgrade to a supported line.
4. Installed from source? After the upgrade, check that the Ruby your GitLab runs on carries GitLab’s Onigmo patch: see GitLab’s patch release notes.
5. Check again with the commands in section A.

• Version files only. Wardlatch reads GitLab’s version files in /opt/gitlab and /home/git/gitlab; the command by hand reads its two VERSION files. GitLab in Docker or Kubernetes isn’t checked yet, nor an install in another folder.
• Ruby, by hand. For an install from source on a fixed version, Wardlatch prints a REVIEW line: it can’t tell whether your Ruby carries GitLab’s Onigmo patch.
• This machine only, on macOS and Linux.

This page describes Wardlatch 0.1.9 and its incident file, gitlab-2026-10.json.

1. GitLab, patch release 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13, 2026-10-21: CVE-2026-110264, critical, CVSS 10.0; the affected and fixed versions; GitLab.com patched, and GitLab Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 or later; database migrations and downtime; the Ruby regular-expression patches.
2. Wardlatch 0.1.9, gitlab-2026-10.json and README: the version files it reads; 18.10 and older get no patch.

Credits · GitLab credits joaxcar, who reported the flaw through GitLab’s HackerOne bug bounty program. All sources read 2026-10-25.