GitLab Fixes 10.0-Rated Flaw: Self-Managed Servers Must Update

This update is for any business, school, agency or software team that runs its own GitLab server. GitLab has released security fixes for a maximum-severity flaw that could let an attacker run code on a server without logging in. If you use GitLab.com, you are already covered. If you host GitLab yourself, you need to upgrade.

What happened

On 21 October 2026, GitLab published patch releases for its Community Edition and Enterprise Edition that fix 12 security vulnerabilities. The most serious, tracked as CVE-2026-110264, carries a CVSS score of 10.0, the highest possible rating.

The bug is an integer overflow in the regular expression compiler. A specially crafted regular expression could trigger it and allow arbitrary code execution on the server. Crucially, it can be reached over the network with no privileges and no user interaction, which is what pushes it to the top of the severity scale. The flaw was reported through GitLab’s HackerOne bug bounty programme by a researcher known as joaxcar.

According to the advisory details reported by GBHackers, the issue affects GitLab versions going all the way back to 7.0.

Fixed versions

GitLab lists the following releases as containing the fixes: 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 and 19.5.1. The fix for the critical code execution bug was also backported to some older branches. GBHackers notes that the full set of fixes for all 12 bugs begins with the 19.3.6, 19.4.3 and 19.5.1 lines, so check the release notes for your exact branch.

The other bugs fixed

The release also patches two high-severity issues and several medium and low ones. The notable ones include:

• CVE-2026-15723 (CVSS 8.2): account takeover of LDAP-backed accounts through OmniAuth SAML and LDAP auto-linking, by an authenticated attacker.
• CVE-2026-112212 (CVSS 7.5): poisoning of the OAuth/OIDC discovery cache, which could redirect sign-in flows.
• CVE-2026-12664 (CVSS 6.8): a GraphQL scope bypass that exposed incoming email addresses.
• CVE-2026-16255 (CVSS 5.9): a bypass of SAML and LDAP membership locks.

The remaining fixes cover issues such as internal credentials exposed in response headers, private project metadata leaking through an API, and approval policy bypasses.

Who is affected

• GitLab.com users: already patched, no action needed.
• GitLab Dedicated customers: tenants on the patched internal builds already include the fixes.
• Self-managed installations: affected until upgraded. This includes on-premises servers and GitLab instances running on cloud virtual machines.

Self-hosted GitLab is popular with banks, fintechs, telecoms, software houses and universities in Nigeria and across Africa that want to keep source code and pipelines under their own control, sometimes for data residency reasons. Those same servers often hold API keys, deployment credentials and connections to production systems, so a compromise can quickly spread beyond the code repository.

Is it being exploited?

The advisory does not indicate exploitation in the wild. GitLab has, however, published two threat detections for self-managed customers to help investigate possible attacks, named “Onigmo native worker crash” and “Org mode render error burst”. Unusual crashes or bursts of rendering errors in your logs are worth a closer look.

Detailed technical write-ups of each issue normally become public 90 days after the fix is released. Once that happens, building an exploit gets easier, so the safest time to patch is now.

Plan the upgrade properly

Upgrading GitLab is usually routine, but a few points help avoid surprises:

• Database migrations: versions 19.3.6 and 19.4.3 include regular database migrations, and 19.4.3 also includes post-deployment migrations. Allow time for these.
• Downtime: single-node installations should expect a short outage during the upgrade. Multi-node environments can follow GitLab’s zero-downtime procedures.
• Upgrade path: if you are several versions behind, use GitLab’s upgrade path guidance rather than jumping straight to the latest release.

What you should do

1. Check your version. In GitLab, open the Help page or the Admin area to see the exact version you are running.
2. Back up first. Run a full GitLab backup and copy the secrets and configuration files somewhere safe.
3. Upgrade to a fixed release for your branch, such as 19.5.1, 19.4.3 or 19.3.6, as soon as possible.
4. Restrict exposure. If your instance does not need to be public, put it behind a VPN or limit access to known IP addresses.
5. Review logs and tokens. Look for the crash and error patterns GitLab describes, and rotate access tokens and CI/CD secrets if anything looks suspicious.
6. Tell your hosting partner. If an outside firm manages your GitLab server, confirm in writing when it will be patched.

Sources

• GBHackers: GitLab patches critical 10.0 RCE vulnerability
• GitLab patch release notes (official patch release index)