GitLab CVE-2026-110264 (CVSS 10): which version to run and what to look for in your logs

What happened

On 21 October 2026 GitLab released patch release 19.5.1 for GitLab Community Edition (CE) and Enterprise Edition (EE). It fixes 12 CVEs. The most severe is CVE-2026-110264, an integer overflow in the regular expression compiler, reported by joaxcar through HackerOne. Its CVSS 3.1 score is 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H): reachable over the network, low complexity, no login, no user interaction. GitLab.com and GitLab Dedicated were already patched. Only self-managed installations need action from you.

Two details are unknown. GitLab does not say what the "certain conditions" are, and the National Vulnerability Database entry was still in status "Received" (not yet analysed) on 22 October. The same release also fixes CVE-2026-15723 (CVSS 8.2) and CVE-2026-112212 (CVSS 7.5).

Which version fixes it

GitLab has had three critical (CVSS 10.0) advisories in six weeks. If you updated for one of them, check that you are past all three.

Read the table by branch. "Fixed in" is the first fixed release; anything newer on the same branch is fine. For CVE-2026-110264, GitLab lists every version from 7.0 up to the fix on each branch as affected. That is why the 12 October releases 19.4.2, 19.3.5 and 19.2.8 and the September backports 19.1.8, 19.0.9 and 18.11.12 (and 19.2.6, 19.3.2) all still need one more update.

What the other two are: CVE-2026-97229 (CVSS 10.0) is an integer overflow in the CI/CD regular expression compiler, exploitable without login. It is not in CISA's catalog, but a public proof-of-concept repository has existed on GitHub since 13 October 2026. CVE-2026-85706 (CVSS 10.0) lets an unauthenticated user read arbitrary files through the repository API. CISA added it to its catalog on 11 September 2026 with a due date of 14 September, which means it has been used in attacks.

How to check your GitLab version

• In the web interface, signed in: choose Help (bottom of the left sidebar). The version is shown at the top. GitLab documents this on its version page.
• On the server: sudo gitlab-rake gitlab:env:info prints the GitLab version and environment details.
• API: /api/v4/version returns the version, but it needs an access token. An anonymous request gets HTTP 401, so outsiders cannot read your version this way.

Compare the result with the table above. If you run several instances (staging, a forgotten test server), check each one.

What to do today

• Find every self-managed GitLab you run and write down its version.
• Upgrade to the fixed release of your branch (table above). GitLab lists no workaround for CVE-2026-110264; upgrading is the remedy. If you are on 19.4.2, 19.3.5 or 19.2.8, you have the earlier fix but not this one.
• If you cannot upgrade today, limiting who can reach the instance (VPN or an IP allow-list at the proxy) reduces exposure. This is general hardening, not a mitigation GitLab documents for this CVE.
• Look at GitLab's built-in detections for the signs below, starting from before 21 October.
• Confirm you are also past the fixes for CVE-2026-97229 and CVE-2026-85706. The second is known to be exploited.
• Separately, check your web servers for GitLab files that should not be public (last section).

What to grep in your logs

GitLab has published no request path or signature for CVE-2026-110264, and we did not find one. So there is no single URL to search for in a web server log. What GitLab ships are two detections, which look at server-side events rather than requests. Their names are "Onigmo native worker crash" and "Org mode render error burst". They are part of GitLab's incident-detection framework, described in Detecting security incidents. Search your GitLab logs and alerts for events matching those two names, and treat a hit as a reason to investigate, not as proof of compromise.

GitLab also published detections for CVE-2026-97229 (six of them) and for CVE-2026-85706. For the latter, GitLab names "LFI attempts reading gitlab.yml" and "LFI via the metadata.path parameter", and the published request markers are file.path or file.size parameters sent to paths under /api/v4/, and a percent-encoded path segment (%66iles). In an nginx or Apache access log, the following finds requests carrying those markers. Query strings are logged, request bodies are not, so a clean result does not rule anything out:

grep -E '/api/v4/[^ "]*(file\.path|file\.size|%66iles)' access.log

Also look for a restart pattern: repeated worker crashes or restarts of GitLab's Ruby processes shortly before an unexplained change. If you find signs of compromise, treat the server as compromised: rotate GitLab secrets, runner tokens and the credentials stored in CI/CD variables after you have patched.

What scanners looked for on four new sites

We run four new sites on one server, this one included. None of them runs GitLab, PHP or WordPress, so every GitLab-related request is a probe by definition. The window is 19 October 2026 16:07 UTC to 22 October 2026 16:30 UTC, 65,847 requests in the Caddy access logs. Our logs record the path and query string, not request bodies, so we can see what was asked for, not what was sent.

• The 25 requests for GitLab instance endpoints look like fingerprinting: the sign-in page and OAuth routes are what a scanner requests to find out whether a host runs GitLab. They are few next to 8,802 requests for .env files. We cannot tell which vulnerability, if any, the sender had in mind. These paths are the same for every GitLab version, so they say nothing about CVE-2026-110264 specifically.
• The 97 requests for .gitlab-ci.yml, .gitlab/ templates and similar names are a different thing. They look for GitLab files that someone deployed into a website folder by accident. A CI file can contain internal hostnames, and /gitlab/.env and /.gitlab-ci/variables.yml are the kind of file that can hold secrets. The risk is a leaked repository copy on a public web server, not an unpatched GitLab.
• The .git directory requests (600) are the same idea: a deployed .git folder can expose a whole repository.
• Nothing in these numbers shows an attack on GitLab. They show that GitLab-related paths are on the lists scanners run against random hosts, next to far more requests for .env files.

We discuss the wider pattern, including how to tell real crawlers from fake ones by IP address, in Fake Googlebots and PHP scanners.

Check your web server for leaked GitLab files

If your site is deployed from a GitLab repository, make sure the repository's dot-files did not end up in the web root. Request these paths on your own domain and expect a 404:

for p in /.gitlab-ci.yml /.gitlab/ /.git/config /.env; do
  printf '%s ' "$p"; curl -s -o /dev/null -w '%{http_code}\n' "https://example.com$p"
done

Replace example.com with your domain. Any answer other than 403 or 404 means the file is public: remove it from the web root, block dot-files in the web server configuration, and rotate any secret the file contained.

Checked 22 October 2026

Every statement about GitLab comes from GitLab's patch release posts and the NVD entries, and the exploitation status from the live CISA catalog (version 2026.10.21, released 21 October 2026). As of 22 October 2026, CVE-2026-110264 was not in CISA's Known Exploited Vulnerabilities catalog, GitLab did not state that it was being exploited, and we knew of no public proof-of-concept or scanner template for it. That can change within hours. CVE-2026-97229 has a public proof-of-concept (GitHub, created 13 October 2026), and CVE-2026-85706 is in the catalog.

Sources: GitLab patch release posts for 19.5.1, 19.4.2 and 19.3.2; NVD for CVE-2026-110264; the CISA Known Exploited Vulnerabilities catalog and its JSON feed; GitLab's pages on checking your version and detecting security incidents; the CVE-2026-97229 proof-of-concept repository (dated 13 October 2026; we have not run it).

How we measured

• Source: the JSON access logs of the web server (Caddy) in front of four new sites on one server, including this one. The sites run Next.js, no PHP, no GitLab.
• Window: 19 October 2026 16:07 UTC to 22 October 2026 16:30 UTC, 65,847 requests. IP addresses were counted, never stored or published.
• A request counts as GitLab-related if its path matches a fixed list of GitLab instance endpoints (such as sign-in and OAuth routes) or of GitLab repository file names (such as .gitlab-ci.yml). The path list may miss variants.
• Limits: three days, one server, four small new sites. Other sites will see other numbers. We cannot see request bodies or which vulnerability a scanner targets.