GitLab has patched a flaw with the maximum CVSS score of 10.0 that could let someone with no account run code on a GitLab server. The bug, CVE-2026-110264, is an integer overflow triggered when GitLab compiles “a specially crafted regular expression”, the company said in its critical patch release on 21 October. It is the second 10.0-rated regex-compiler flaw GitLab has fixed in ten days.
The reach is what sets this one apart. GitLab’s affected range starts at version 7.0 and runs through every current line, where the earlier flaw touched only three recent releases. Singapore’s Cyber Security Agency has issued an alert telling users to patch immediately. No exploitation has been reported.
Fixed releases cover seven versions, back to 18.11
GitLab says the flaw affects Community Edition (CE) and Enterprise Edition (EE), “all versions from 7.0 before 18.11.13, 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”. The fixed versions are 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. GitLab says it backported the fix to 18.11.13, 19.0.10, 19.1.9 and 19.2.9, beyond its usual patch releases.
GitLab “strongly recommend[s]” that all self-managed installations upgrade “immediately”. GitLab.com already runs the patched version. GitLab Dedicated tenants on 19.3.5-internal0 and 19.4.2-internal0 or later already have the fixes and need to take no action, the company says. GitLab has also released two threat detections to help self-managed customers spot attempts to exploit the flaw.
In CVSS terms, the vector GitLab publishes, AV:N/AC:L/PR:N/UI:N/S:C, means an attack over the network, with low complexity, no privileges and no user interaction, and an impact that reaches beyond the vulnerable component. GitLab credits the researcher joaxcar, who reported it through its HackerOne bug bounty programme.
The same release fixes 11 other issues. Two are rated high: CVE-2026-15723 (CVSS 8.2), which could let an authenticated user take over an existing LDAP-backed account when OmniAuth SAML and LDAP auto-linking are both enabled, and CVE-2026-112212 (7.5), which could let an unauthenticated user poison a cached OAuth/OIDC discovery document to redirect certain flows to an outside server. Five are rated medium and four low.
Researchers count more than 2,700 exposed GitLab CE servers
BleepingComputer reports that joaxcar also reported CVE-2026-97229, the earlier 10.0 flaw, which TSN covered on 12 October. It adds that the internet watchdog Shadowserver tracks more than 2,700 GitLab CE instances exposed online, but gives no figure for how many are honeypots or already patched. That number describes exposure, not confirmed vulnerable servers.
BleepingComputer also notes that a separate maximum-severity GitLab flaw fixed last month, CVE-2026-85706, was added to the US Cybersecurity and Infrastructure Security Agency’s list of exploited vulnerabilities one day after its fix. Nothing similar has been reported for CVE-2026-110264.
A wider version range makes this patch harder to skip
Two 10.0 flaws from the same researcher in the same part of GitLab within ten days suggest the regex compiler is getting close scrutiny, and that it has more than one weak point. The earlier bug was confined to the CI/CD regex path in versions 19.2 to 19.4. This one, as GitLab describes it, is not tied to CI/CD and reaches back to 7.0. That changes who needs to act. Teams that checked their version against the 12 October advisory and found themselves outside its range may now be inside this one.
GitLab’s backports matter for the same reason. By shipping fixes to 18.11 and every 19.x line, it gives organisations that pin older releases a path that avoids a major upgrade. What it does not give is detail. GitLab does not say which input reaches the vulnerable compiler, and it keeps security issues private for 90 days after a fix. Defenders therefore cannot judge from GitLab’s text whether their own configuration narrows the risk, which leaves patching as the only reliable response.
The CISA history explains the urgency, even without any reported attack. A maximum-severity GitLab bug last month moved from fix to exploited list in a day. It also lands in a crowded month, after Oracle shipped 1,295 patches and SAP fixed its own 10.0 flaw. The next signal to watch is whether Shadowserver’s exposed count starts falling, or whether CVE-2026-110264 follows its predecessor onto CISA’s list.
Sources
- GitLab: GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13 (21 October 2026)
- Cyber Security Agency of Singapore: Critical Vulnerability in GitLab, AL-2026-152 (22 October 2026)
- BleepingComputer: GitLab warns of new max severity code execution vulnerability (Sergiu Gatlan, 22 October 2026)
Related stories
- GitLab Patches CVE-2026-97229, a CVSS 10.0 Flaw That Could Let an Unauthenticated User Run Code Through a Crafted CI/CD Regex
- SAP Fixes Maximum-Severity OAuth2 Flaw in Its Cloud SDK for Python in October 2026 Patch Day
Follow @tsnmediahub on X for breaking AI news as it happens.
Follow on X





