GitLab released updates Wednesday for a flaw that could let an attacker without an account run code on self-managed GitLab servers, the second bug with the maximum severity score that the company has fixed in under two weeks. GitLab servers hold companies' source code and the credentials used to build and ship software, so organizations that host their own face another emergency upgrade.
What Happened
GitLab's patch release ships versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13 of its Community and Enterprise Editions. The critical flaw, CVE-2026-110264, scores 10.0, the top of the Common Vulnerability Scoring System (CVSS). It is an integer overflow, an arithmetic error in which a number outgrows the space reserved for it, that occurs when GitLab compiles a specially crafted regular expression, a text-matching pattern. GitLab says that under certain conditions it could let an unauthenticated user execute arbitrary code on the server.
Every version from 7.0 onward is affected until the fixed releases. GitLab.com already runs the fix, and tenants of GitLab Dedicated, the company's single-tenant hosted service, on 19.3.5-internal0, 19.4.2-internal0 or later need not act. GitLab "strongly" recommends that affected installations be upgraded as soon as possible.
A researcher using the handle "joaxcar" reported the flaw through GitLab's HackerOne bug bounty program, as with the previous critical bug. GitLab's notes do not report exploitation. The company published two detection rules that administrators of self-managed servers can use to spot attempts against the bug. The update includes database migrations, so single-node installations will go offline while it applies; multi-node setups can use zero-downtime procedures.
The release fixes 11 other security issues: two high, five medium and four low severity. One high-severity flaw (8.2) could let a signed-in user take over an existing directory-backed account when SAML single sign-on and LDAP account auto-linking are both enabled. The other (7.5) could let an attacker without an account poison a shared cache so that certain sign-in flows redirect to an outside server. A low-severity fix stops group owners from re-enabling data flows to a third-party AI service after an administrator has locked that setting.
Why It Matters
Two perfect-score, no-login flaws in nine days in the same type of component turn GitLab patching into a recurring emergency rather than routine maintenance. Code execution on a build server can expose proprietary code and deployment credentials, and could let an intruder tamper with software before it ships.
The reach back to version 7.0 matters for executives because old GitLab servers often survive outside central IT, set up by individual teams and never retired. Leaders should ask whether every self-hosted instance is inventoried, which are reachable from the internet, and who owns the downtime window for the upgrade.
Context
On Oct. 12 GitLab fixed CVE-2026-97229, a 10.0-rated flaw in the regular expression compiler used for CI/CD pipeline files, The Primary Wire reported last week. Attackers have moved quickly on GitLab flaws before. After GitLab patched a maximum-severity path traversal flaw, CVE-2026-85706, last month, CISA added it to its Known Exploited Vulnerabilities (KEV) catalog a day later, BleepingComputer has reported. The KEV catalog is the U.S. government's list of flaws confirmed to be under attack. CISA has flagged five GitLab flaws as exploited since November 2021, one of them in ransomware attacks, according to the outlet.
What to Watch
- Public exploit code or reports of attacks, and any addition of CVE-2026-110264 to the KEV catalog.
- Upgrade uptake on internet-facing self-managed servers.
- GitLab's publication of issue details, which it says comes 90 days after a patch release and will show how the bug works.
