GitLab shipped an emergency patch on October 21 for CVE-2026-110264, a flaw rated CVSS 10.0 that can let an unauthenticated attacker run code on self-managed GitLab servers. According to GitLab's patch release notes, the bug reaches back to version 7.0, released in 2014, so the affected range spans more than a decade of releases.
This is the second critical GitLab patch in nine days. GitLab's October 12 update fixed a related regex bug, tracked as CVE-2026-97229, but it did not cover older branches and did not address the new flaw. Instances on the 19.2 through 19.4 lines stay exposed until they move to a fixed release.
Self-managed GitLab runs at many US enterprises, software companies and government contractors, which makes the exposure broad. GitLab.com, the hosted service, already runs the fixed version, according to the Konfirmity advisory. The work falls on customers who host their own servers.
Which GitLab versions are affected and what to install
GitLab's release notes list fixes for both Community and Enterprise Editions. Byteiota summarizes the vulnerable range as every version since 2014, according to its write-up. Match your installed version to its release line, then move to the fixed version on that line.
| Release line | Fixed version |
|---|---|
| 19.5 | 19.5.1 |
| 19.4 | 19.4.3 |
| 19.3 | 19.3.6 |
| 19.2 | 19.2.9 |
| 19.1 | 19.1.9 |
| 19.0 | 19.0.10 |
| 18.11 | 18.11.13 |
Installs on 18.10 or older have no fixed release on their own line. The Konfirmity advisory says those servers need a planned upgrade path to 18.11.13 or later. GitLab offers no workaround, so upgrading is the only fix.
Why the October 12 patch left 19.2 to 19.4 installs exposed
GitLab's October 12 fix covered CVE-2026-97229, a CVSS 3.1 10.0 bug in the same CI/CD regex compiler area. Its fixed versions were 19.2.8, 19.3.5 and 19.4.2. Rapid7's analysis of the earlier bug reproduced code execution against the official 19.4.1 CE image and said the 19.4.2 image blocked the same input.
That earlier bug requires a malicious CI/CD configuration to be planted in a repository first. Rapid7 notes that this constraint disappears on instances where new users can self-register and create projects.
The new release matters most for anyone who patched on October 12. Because the new fixes sit one patch above the earlier ones, an instance on 19.2.8, 19.3.5 or 19.4.2 falls back into the affected range for CVE-2026-110264. The target is 19.2.9, 19.3.6 or 19.4.3.
Plan for downtime on single-node servers. The 19.4.3 and 19.3.6 releases include database changes that run during the upgrade, and on a single-node server that means the instance is offline while they finish, according to The Hacker News.
Some outlets have swapped the two CVE numbers. GitLab's own advisory assigns CVE-2026-110264 to the October 21 release, while Rapid7 and Safeguard use CVE-2026-97229 for the October 12 bug. Check the numbers against GitLab's advisory before you record them in a ticket or a compliance report.
What an attacker gains and who should worry most
IT and DevOps teams, security leads and developers at companies that run self-managed Community or Enterprise Edition are the most affected group. That includes government, finance and defense contracting. This group is an inference from the affected product, not a sourced statistic.
Code execution on the server is the serious part. Safeguard.sh's guide to the October 12 bug says code execution on the GitLab server reaches CI/CD variables, runner registration tokens and deploy keys. Protected variables that hold cloud credentials are the first place to look after patching.
Those items reach well beyond the GitLab server. A runner registration token can attach a new machine to the instance, and a deploy key can open access to repositories. An intruder with those assets can affect builds and code, not just one server.
The same release also fixes two high-severity bugs. CVE-2026-15723, rated 8.2, could let a logged-in user take over another account, but only when an administrator has enabled both SAML and LDAP auto-linking. CVE-2026-112212, rated 7.5, is a cache-poisoning flaw in GitLab's OAuth and OpenID Connect endpoints. Admins who use SAML or LDAP auto-linking should review that setting after upgrading.
Is there evidence of exploitation yet?
The public record is thin and in places conflicting. SecurityOnline, citing GitLab's advisory, reports that no public proof of concept exists for the October 21 bugs and that no active exploitation has been confirmed.
A HOL write-up carries a headline claiming attackers took over GitLab servers through a crafted Org-mode file, even after the October 12 patch. The sources reviewed for this story did not include an independent exploit report confirming that claim, so treat it as unverified until one appears.
Headlines call the new flaw unauthenticated. Rapid7's analysis of the earlier bug shows an attacker may first need to plant a CI/CD configuration, unless self-registration is open. Confirm the exact preconditions for CVE-2026-110264 against GitLab's advisory before you rely on either description.
Coverage also disagrees on how many issues the October 21 release fixes. Sources cite 11 total fixes, 12 total, or one critical plus 11 others. Read the release notes for the full list rather than relying on a headline count.
No victim reports tied to this patch appeared in the sources reviewed, and nothing shows whether a US organization has been hit.
Steps to take today for GitLab servers
Work through these steps on every self-managed instance, including staging and test servers.
- Find the exact GitLab version on each instance and compare it with the fixed-release table above.
- Upgrade to the fixed version on your release line today. GitLab offers no workaround, so upgrading is the only fix.
- If the server runs 18.10 or older, plan the path to 18.11.13 or later and rehearse it on a copy of the instance first.
- If the instance was internet-exposed while running an affected version, rotate secrets, starting with protected variables that hold cloud credentials.
- Turn off open self-registration and project creation if you do not need them. Rapid7 says that removes the planting step for the earlier bug.
- Check logs for exploitation attempts. GitLab's advisory includes a section on detecting exploitation, but this article did not verify its contents, so read that section directly.
Single-node servers running 19.4.3 or 19.3.6 will be offline while database changes finish, so schedule a maintenance window before you start.
What comes next for GitLab and self-hosted teams
Three things bear watching. First, whether independent researchers publish a reproduction for the October 21 bugs, which would change the urgency for admins who have not patched. Second, whether GitLab settles the CVE numbering and fix count in its advisory. Third, whether GitLab offers clearer guidance for installs on 18.10 and older.
The same day, a LiteLLM supply-chain compromise delivered a credential stealer to Python developers, according to The Hacker News. That incident is separate, but it targets the same kind of developer infrastructure. USA 24 has also covered a returning GhostAction wave that stole GitHub accounts and an Atlassian flaw under active attack.
Teams that patch now and rotate exposed secrets will not need to wait for a confirmed exploit report before they act.
