Say your company has an in-house development team, or a contractor building systems for you, and all of the code lives in a GitLab instance on your own server. That server usually holds more than code: pipeline settings, deployment passwords, and access paths into production.
If an outsider could run commands on that machine without logging in, the damage would not stop at GitLab. This week's news is about exactly that kind of risk.
What happened
On 21 October 2026 GitLab released seven patch versions at once: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13, for both Community Edition and Enterprise Edition. GitLab recommends that self-managed installations upgrade as soon as possible.
The release fixes 12 vulnerabilities. The most serious is CVE-2026-110264, rated CVSS 10.0, the top of the scale. The bug sits in the regular expression compiler. A specially crafted regex triggers an integer overflow, and under certain conditions an unauthenticated user could execute arbitrary code on the GitLab server.
The affected range is wide: every version from 7.0 up to the fixed release in each branch. That is why GitLab also backported the fix to older branches 18.11, 19.0, 19.1 and 19.2 on top of its normal patch cycle.
Two high-severity fixes are also worth knowing about:
- CVE-2026-15723, rated 8.2, in OmniAuth-to-LDAP automatic account linking
- CVE-2026-112212, rated 7.5, a cache poisoning issue in the OAuth and OIDC discovery endpoints
Who needs to act
GitLab says GitLab.com already runs the patched version. GitLab Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 and later need no action.
The group that has to do something is every organization running self-managed GitLab, whether on its own servers or on cloud machines the team operates itself.
On exploitation, GitLab's release post does not report attacks in the wild. SecurityOnline reported on 21 October that no exploitation had been confirmed and no public proof of concept existed. That is not a reason to wait. Once a patch is public, people can compare it with the old code to find what changed, and GitLab publishes each issue's details 90 days after the fix. The longer a server stays on an old version, the higher the risk.
