GitLab’s Third Critical Patch in Six Weeks: What CVE-2026–110264 Means for Your Source Code, Your…

On October 21, 2026, GitLab released an out-of-band critical patch for CVE-2026–110264. The flaw is rated CVSS 10.0, the maximum. It is an integer overflow in a regular-expression compiler that, under certain conditions, lets an unauthenticated attacker run arbitrary code on a self-managed GitLab server. The Hacker News reports it affects every release back to GitLab 7.0, which shipped in 2014.

GitLab is where many companies keep their source code, run the pipelines that build and deploy it, and store the credentials those pipelines need. Code execution on that server is a compromise of your software delivery chain, and often of your cloud accounts too. This post covers what happened, how to find out whether you are affected, how to patch (including a detail that catches people who already patched), and how to limit the damage if an unpatched instance was reachable. It then covers the structural lesson: why the secrets stored inside GitLab are the real risk.

One note on scope. This is not GitLab's first critical flaw this autumn, and the different CVEs are easy to confuse. A short section below separates them.

What Happened

GitLab fixed CVE-2026–110264 on October 21, and NVD published the record on October 22. Per Censys's advisory, the key facts are:

• The flaw: an integer overflow in the regular-expression compiler, scored CVSS v3.1 10.0 by GitLab. GitLab's patch notes say an unauthenticated user could execute arbitrary code on the GitLab server using a specially crafted regular expression.
• Who is affected: self-managed GitLab Community Edition and Enterprise Edition, on all deployment types. GitLab.com and GitLab Dedicated are already patched and need no action.
• Which versions: 7.0 through 18.11.12, 19.0.0 through 19.0.9, 19.1.0 through 19.1.8, 19.2.0 through 19.2.8, 19.3.0 through 19.3.5, 19.4.0 through 19.4.2, and 19.5.0.
• Where the bug lives: The Hacker News explains that the compiler is Ruby's built-in engine, Onigmo, which GitLab ships inside its own packages. A weakness in that engine is present in every release that shipped it, which is why the flaw reaches back to 2014.
• The reported trigger: At first, GitLab did not say what conditions an attacker needs. Censys later reported that GitLab's own detection write-ups place the flaw in the renderer for Org-mode (.org) files, where a keyword from a #+TODO: line is passed into a regular expression. Per those write-ups, the attack needs no authentication, only one public project that can hold the .org payload.
• Exploitation status: As of October 22, neither GitLab, Censys nor The Hacker News reported exploitation in the wild, and the flaw was not in CISA's Known Exploited Vulnerabilities catalog. Censys also reported no public proof of concept at that point. Check CISA's catalog and GitLab's advisory for current status before you assume that still holds.

The scale matters. On the day of disclosure, Censys observed roughly 82,000 hosts and about 209,000 web properties running GitLab. Since every release up to the fix is affected, effectively that whole population was in range. Censys estimates more than half of internet-exposed GitLab servers run a release line more than seven months old that gets no fix of its own, and more than a quarter are three or more major versions behind. Those servers can only be fixed by upgrading to a newer release line.

What an Attacker Gets If It Works

Code execution on GitLab runs as the git user. Per GitLab's detection guidance, as summarized by Censys, that exposes:

• the instance secrets in gitlab-secrets.json
• every CI/CD variable
• runner and access tokens
• read and write access to every repository on the instance

Consider what that means in practice. CI/CD variables routinely hold cloud credentials, deploy keys, registry tokens and signing keys. Write access to every repository means an attacker can alter code or pipeline definitions that your build systems will then trust and run. For an engineering organization, a GitLab server is the control plane for how software reaches production.

This is also why we say a patch alone is not an adequate response to flaws like this one. The patch closes the door. It does nothing about what an attacker took while the door was open.

Three GitLab CVEs You Should Not Confuse

GitLab has had a rough autumn, and reporting often blends the CVEs together. They are separate problems with different conditions.

The Hacker News reports that CVE-2026–110264 is the fourth code-execution flaw in GitLab's regular-expression engine reported by the same researcher in a month. Two earlier ones on September 23 (CVE-2026–93577 and CVE-2026–89078, both 9.9) required a logged-in account.

The file-read flaw, CVE-2026–85706, deserves attention even though it is a separate bug. According to CrowdSec, it has been actively exploited since September 11, with 1,022 unique source IPs observed through October 5. Public tooling reduces the attack to a single HTTP request, and public proofs of concept list gitlab-secrets.json and gitlab.rb as targets. If your instance was reachable and unpatched after September 10 and had a public project, assume those files may have been read. We return to that in the rotation section.

The Patching Trap: "We Already Patched on October 12"

This is the detail most likely to bite you.

If you upgraded on October 12 to fix CVE-2026–97229, you installed 19.4.2, 19.3.5 or 19.2.8. Each of those sits one patch below the fix for CVE-2026–110264. An instance patched nine days ago is in the vulnerable range again. Do not assume you are covered.

Here are the fixed versions for each release line:

GitLab backported the fix to 18.11.13, 19.0.10, 19.1.9 and 19.2.9 on top of its standard releases, which it reserves for severe issues. If you are on an older line than 18.11, there is no fix for your branch. You need to upgrade to a supported line, stepping through GitLab's required upgrade stops.

Two practical points for planning:

• Downtime. The 19.4.3 and 19.3.6 releases include database changes that run during the upgrade. On a single-node server, that means downtime while they finish. Multi-node setups can use GitLab's zero-downtime procedure.
• No workaround. The Hacker News reports GitLab's advisory offers no interim workaround, and since the preconditions weren't published at first, you can't rule yourself out by configuration. The fix is the only certain protection.

You can confirm your version with sudo gitlab-rake gitlab:env:info on Linux package installations, or from the Admin area dashboard.

If You Cannot Patch Today

Sometimes the upgrade path is long and needs a maintenance window. In the meantime, reduce the odds, but treat these as stopgaps and not as fixes.

• Narrow who can reach the instance. If GitLab is internet-facing only for convenience, put it behind a VPN, an allowlist or an identity-aware proxy. An unreachable server can't be exploited remotely.
• Reduce the public-project precondition. Censys, citing GitLab's write-ups, says the reported path requires a public project to hold the payload. Converting public projects to internal or private, and restricting anonymous access and public project creation, narrows that path. Rapid7 makes a similar point about CVE-2026–97229, noting that such controls address only the demonstrated delivery path and do not fix the vulnerable compiler.
• Turn on detection now. GitLab published two Sigma detections in its open-source TLDR framework, "Onigmo native worker crash" and "Org mode render error burst," that run against GitLab's own application logs.
• Schedule the upgrade with a date. Mitigations without a deadline tend to become permanent.

How to Tell Whether Someone Got In

If your instance was reachable and unpatched, look for signs of code execution. GitLab's guidance, via Censys, lists these:

• unexpected child processes of Puma
• new files owned by git in /tmp
• changed crontabs or SSH keys for the git user

Here are some read-only starting points on a Linux package install:

# Unexpected processes spawned under Puma / the git user
ps -eo pid,ppid,user,lstart,cmd --forest | grep -A4 -i puma

# New or recently modified files owned by git in /tmp
sudo find /tmp -user git -newermt "2026-10-12" -ls

# Crontab entries for the git user
sudo crontab -l -u git

# Authorized SSH keys for the git user (path varies by install type;
# on Omnibus installs it is typically under /var/opt/gitlab/.ssh/)
sudo ls -la /var/opt/gitlab/.ssh/ 2>/dev/null

# Unexpected processes spawned under Puma / the git user
ps -eo pid,ppid,user,lstart,cmd --forest | grep -A4 -i puma

# New or recently modified files owned by git in /tmp
sudo find /tmp -user git -newermt "2026-10-12" -ls

# Crontab entries for the git user
sudo crontab -l -u git

# Authorized SSH keys for the git user (path varies by install type;
# on Omnibus installs it is typically under /var/opt/gitlab/.ssh/)
sudo ls -la /var/opt/gitlab/.ssh/ 2>/dev/null

Also review production_json.log and the other application logs for crash bursts and .org rendering errors, and check public projects for unexpected .org files. Forward logs off-host where you can, since an attacker with code execution as git could tamper with local logs.

GitLab's guidance is clear on the next step: where these signs appear, treat the instance as compromised and rotate its secrets. The same logic applies if you can't prove a clean history. With a bug this severe and an exposed, unpatched server, "I saw nothing" doesn't prove nothing happened. A file read in particular leaves little behind, as CrowdSec notes about CVE-2026–85706.

The Rotation Checklist

Patching ends the exposure. Rotation ends the consequences. Work through these, starting with what reaches outside GitLab:

1. CI/CD variables. This is the highest-value set: cloud credentials (AWS, Azure, GCP), deploy tokens, registry credentials, signing keys and third-party API keys. Rotate them at the provider, not just in GitLab.
2. Runner tokens. Reset runner registration and authentication tokens, and re-register runners.
3. Access tokens. Revoke and reissue personal, project and group access tokens, and deploy keys.
4. Integration and service credentials. Rotate anything GitLab uses to talk to other systems: webhooks secrets, OAuth application secrets, Kubernetes integrations, and credentials in gitlab.rb for the database, LDAP, SMTP and object storage.
5. The keys in gitlab-secrets.json. These encrypt CI/CD variables and sign sessions. CrowdSec points out that they decrypt data already in the database, so changing them is a planned project, not a one-line command. Plan it. Don't skip it.
6. Review what changed. Audit recent commits, pipeline definitions, merge requests, new users and new SSH keys for anything you can't explain. Since an attacker with write access can alter code that your builds trust, check build artifacts from the exposure window too.
7. Look outward. Search your cloud audit logs for use of the credentials you just rotated, in particular from unfamiliar IP addresses or at odd hours. A stolen key usually shows up in the cloud account before it shows up anywhere else.

Why This Keeps Happening, and What It Teaches

GitLab is not unusually careless. A widely deployed Ruby regex engine had a flaw, and the same researcher kept finding variants of it. Fixes landed quickly, across seven branches at once. That is a vendor responding well. The lessons for defenders are less about GitLab and more about what we keep inside it.

• Your SCM server is a crown-jewel system. Many organizations treat GitLab like an internal tool. It is closer to a domain controller for your delivery pipeline. It holds credentials, it can change what production runs, and it is often reachable from the internet so contractors and remote staff can use it.
• Secrets stored as CI/CD variables turn a server compromise into a cloud compromise. This is the real multiplier. If your pipeline needs to deploy to AWS, how it authenticates decides the blast radius when GitLab is breached. A long-lived access key stored as a CI variable is valid for as long as it exists, and the attacker gets all of it. A short-lived credential issued per job through OIDC federation, or access granted just in time, is worth far less once stolen.
• Severity scores don't tell you your risk. CVSS 10.0 applies to every GitLab instance equally. What matters to you is whether yours is internet-facing, how old it is, which public projects exist, and what credentials sit behind it. A forgotten, internet-facing, three-major-versions-behind GitLab server that holds production cloud keys is a very different risk from a patched internal one, even though they share a CVE number. We make this argument in why flat per-rule severity is broken.
• Patching speed depends on inventory. The first question in the first hour was "where do we run GitLab, and which versions?" Teams that could answer in minutes moved fast. Teams that couldn't spent days. Censys's numbers suggest a large share of exposed servers are well behind on versions, which is also an inventory and ownership problem.

The Structural Fixes

These steps make the next GitLab flaw, or a flaw in any other CI/CD platform, much less painful.

1. Reduce exposure. Keep SCM and CI systems off the public internet where you can. Use a VPN or identity-aware proxy. Review which projects genuinely need to be public.
2. Remove long-lived cloud keys from CI/CD variables. Use short-lived, identity-based credentials per job. Where a human or a pipeline needs elevated cloud access, grant it for a limited time and revoke it automatically. We cover the approach in governing CI/CD pipeline credentials without standing secrets, and our GitLab CI/CD security checklist has concrete settings.
3. Scope CI secrets tightly. Use protected variables, environment-scoped secrets, and protected branches, so a secret is only available to the jobs that need it.
4. Keep an inventory with owners and versions. Know every GitLab instance, who runs it, and what version it's on. Track end-of-life release lines.
5. Watch repository activity. New SSH keys, new access tokens, unexpected pipeline changes and odd permission grants are early signs of tampering. See our post on why watching your SCM activity matters.
6. Know your blast radius ahead of time. Be able to answer "if this GitLab server were compromised right now, which cloud accounts, clusters and data could the stored credentials reach?" Our walkthrough, code-to-cloud security explained: following a vulnerability from GitLab to a running ECS task, shows what that trace looks like in practice.
7. Practice the rotation. Rotating every CI/CD secret is a muscle. If it takes your team a week the first time you try it, do the first run before you need to.

Where Cloudanix Fits

Let us be direct about what a platform can and can't do here. Cloudanix doesn't patch your GitLab server, and nothing but the upgrade closes CVE-2026–110264. Where we help is the part that decides how bad a compromise gets.

• Credentials and access. With Just-in-Time access, access to cloud accounts, databases and Kubernetes is granted on request, scoped, and automatically revoked, including for service accounts and pipelines. That means the credentials sitting behind a CI system are short-lived by design, so a stolen one is worth much less.
• Attack paths and blast radius. The unified asset graph correlates cloud resources, identities and code context, so "what could this compromised system reach?" becomes one query instead of a multi-tool investigation. The idea is explained in what an attack path is and why isolated findings mislead you.
• Code and pipeline security across SCMs. Cloudanix code security works across GitHub, GitLab, Bitbucket and Azure DevOps, scanning for secrets and vulnerabilities, so credentials hardcoded in repositories and pipeline files get found and fixed. See one code security layer across your SCMs.
• Exposure over patch lists. We have written about why the real question in incidents like this is exposure management, not just patching, and we saw the same pattern in a recent edge-device zero-day.

If you'd like to see where long-lived credentials and standing access sit in your own environment, you can start with a free security assessment at cloudanix.com.

The Takeaway

For GitLab self-managed customers, the immediate to-do list is short. Upgrade to the fixed version for your line, including if you patched on October 12. Check for signs of compromise. If there's any doubt about an exposed, unpatched instance, rotate the secrets it holds, starting with CI/CD variables and cloud credentials.

The longer-term lesson is about what we put inside our delivery systems. GitLab will have another critical bug someday, and so will every other CI/CD platform. When that happens, the question that decides the outcome isn't how fast you patched. It's whether the credentials on that server were short-lived and narrowly scoped, or long-lived and powerful. Make them the former, and the next 10.0 becomes a maintenance window instead of an incident.