GitLab Has Another 10/10 Flaw: Patch Again After Oct 12

On October 21, 2026, GitLab shipped a critical patch for another flaw rated 10 out of 10 that, under certain conditions, lets someone run code on the server without logging in. It affects self-managed GitLab from version 7.0 onward, including instances updated on October 12. GitLab.com is already fixed.

What we know

What GitLab released: according to its October 21 patch release note, versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13 of the Community and Enterprise editions. They fix 12 security issues: 1 critical, 2 high, 5 medium and 4 low.
The critical flaw: the note describes CVE-2026-110264 as an integer overflow when compiling a specially crafted regular expression. GitLab says that under certain conditions an unauthenticated user could execute code on the server. It is rated 10.0 on the CVSS scale.
Affected versions: per GitLab, everything from 7.0 before 18.11.13, plus 19.0 before 19.0.10, 19.1 before 19.1.9, 19.2 before 19.2.9, 19.3 before 19.3.6, 19.4 before 19.4.3 and 19.5 before 19.5.1.
Not the October 12 flaw: that one was CVE-2026-97229, fixed in 19.4.2, 19.3.5 and 19.2.8. All three of those versions fall inside the new affected range.
Where the bug lives: according to The Hacker News, in Onigmo, the Ruby regular expression engine GitLab ships in its packages. The same outlet says there is no workaround: updating is the only fix.
Who found it: the same researcher as on October 12, "joaxcar," through GitLab's HackerOne bug bounty program.
Who doesn't need to act: GitLab.com already runs the fixed version. GitLab Dedicated tenants on 19.3.5-internal0, 19.4.2-internal0 or later already have the fix.
Downtime: the patch includes database migrations. Single-node instances will go down during the upgrade, because migrations must finish before GitLab starts. Multi-node setups can upgrade without downtime.
Attacks: GitLab's note does not mention active exploitation. The Hacker News says the flaw was not in CISA's Known Exploited Vulnerabilities catalog. GitLab published two detection rules for self-managed instances.

What changes and what doesn't

If your team keeps the website's code on GitLab.com, there is nothing to do.

It does change things for anyone running their own GitLab on a server or VPS. Updating on October 12 is not enough: the version installed that day carries the new flaw.

It also changes things for anyone who stayed on a version older than 19.2. The October 12 patch didn't cover those branches; this one does, and the oldest version that gets the fix is 18.11.13. Anyone below the 18.11 branch has to move to at least that version.

The other issues in the release involve permissions, authentication, caching and exposure of internal credentials. The same versions fix them.

How to tell if you're affected

Check where your GitLab lives. If you sign in at gitlab.com, you're covered. If you use your own address (say, git.yourcompany.com), keep going.
Check the version. An admin account can see it in the Admin area and on your instance's /help page.
Pick the target version for your branch: 19.5.x → 19.5.1; 19.4.x (including October 12's 19.4.2) → 19.4.3; 19.3.x (including 19.3.5) → 19.3.6; 19.2.x (including 19.2.8) → 19.2.9; 19.1.x → 19.1.9; 19.0.x → 19.0.10; 18.11 or older → at least 18.11.13.
Plan the downtime. On a single server there will be no pushes or website deployments during the upgrade. Take a backup first.
Review deployments. If your GitLab was reachable from the internet on an affected version, consider rotating the credentials your site uses to deploy (hosting access, FTP, APIs) stored as CI/CD variables.
If someone else runs the server, ask them: "Which GitLab version are we on, and when do we move to the October 21 patch for our branch?"

Sources

Updates: this article will note it if GitLab or another primary source reports attacks using this flaw.