GitLab CVE-2026-110264: Patch the CVSS 10 Self-Managed RCE Now

CVE-2026-110264 is a CVSS 10.0 flaw in self-managed GitLab CE and EE that, according to GitLab, could let an unauthenticated user run code on the server. Every version from 7.0 is affected. GitLab.com and GitLab Dedicated are already patched. If you run your own GitLab, upgrade to the fixed build for your branch today.

GitLab shipped the fix on 21 October 2026 for seven version lines, from 18.11.13 to 19.5.1. As of 22 October, GitLab's advisory does not report exploitation, the flaw is not in CISA's Known Exploited Vulnerabilities catalog, and reporting we read found no public proof of concept. That is a window, not a guarantee. A GitLab server holds your source code, your CI/CD secrets and the tokens your runners use to reach production, so it deserves the same urgency as the edge device zero days of October 2026.

Below: what GitLab has confirmed, version checks, upgrade paths, what to rotate if the server may have been reached, and what would have helped. No exploit details.

What happened

GitLab publishes security fixes in patch releases. Scheduled ones come out twice a month, and ad hoc critical patches ship when a high severity issue needs it. October 2026 had two critical ones in nine days.

The two flaws are separate. Cybersecurity News and Konfirmity both say the 12 October update does not fix CVE-2026-110264, and GitLab's own version tables agree: 19.4.2 is the fixed build for the first flaw but is inside the affected range for the second. If you patched on 12 October, you need to patch again.

The facts from GitLab's advisory

GitLab's release note is the primary source. Here is what it states, and what it leaves out.

The vector explains the 10.0: reachable over the network, low complexity, no privileges, no user interaction, changed scope and full impact. In plain terms, anyone who can reach the server, with the worst outcome.

The same release fixes 11 other issues, including two rated high: CVE-2026-15723 (8.2) in OmniAuth to LDAP auto linking, and CVE-2026-112212 (7.5), cache poisoning in OAuth and OIDC discovery endpoints. The same upgrade fixes them.

What "affects 7.0 onward" means in practice

Cybersecurity News dates GitLab 7.0 to 2014. The practical point: no old version avoids this, and anything older than 18.11 has no patch on its own branch. Those servers must move forward through the upgrade path, covered below.

How it works, in plain language

GitLab's advisory says the bug is an integer overflow when GitLab compiles a specially crafted regular expression. A regular expression compiler turns a pattern into an internal program the engine can run. If a size or count inside that process overflows, the engine can end up reading or writing memory it should not touch, and in the worst case that turns into code execution.

GitLab's detection rules add context without giving a recipe. The "Onigmo native worker crash" rule watches for crashes in Onigmo, the regular expression engine inside Ruby, or in the org-ruby gem that renders Org mode files. The "Org mode render error burst" rule watches for repeated render timeouts on .org files. The detection write-up says the attack needs no authentication, only a public project GitLab will render, and that code would run as the git user. The release notes also list a patch to Ruby's regular expression handling among the bug fixes.

For defenders, that means three things. Public projects are the exposure surface for unauthenticated users. Attacker code would run as the GitLab application user, which can read repositories, GitLab's database credentials and the secrets GitLab stores. And a crash is not required: GitLab's own rule says a successful exploit may be silent. Beyond that, the details that matter are the version numbers.

Who is affected

Do not forget the servers nobody thinks about. Konfirmity's advisory rightly lists Geo secondaries, staging, disaster recovery and test instances. An instance reachable only from a private network is still affected; fewer people can reach it, which changes your order of work, not the need to patch.

What to do now

Work through this in order. It assumes a Linux package (Omnibus) install; notes for Docker and Helm follow.

1. Find every GitLab instance. Check DNS, your cloud inventory, and your runner configs (every runner's config.toml names the GitLab URL it talks to). List production, Geo secondaries, staging, DR and any personal test servers.

2. Check the version on each one.

   # Linux package install
   sudo gitlab-rake gitlab:env:info | grep -A2 "GitLab information"
   cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
   
   # Docker
   docker exec gitlab cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
   
   # Remotely, with a token that has read_api scope
   curl --silent --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
     "https://gitlab.example.com/api/v4/version"
   

   For Helm, helm list -n gitlab shows the chart, and the chart's app version maps to a GitLab version. Compare the result with the table above.

3. Check exposure while you prepare the upgrade. Is the instance reachable from the internet? Does it have public projects?

   curl --silent --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
     "https://gitlab.example.com/api/v4/projects?visibility=public&per_page=100" \
     | jq -r '.[].path_with_namespace'
   

   GitLab's detection write-up names reducing public project visibility as an interim mitigation. Admins can restrict the Public level under Admin, Settings, General, Visibility and access controls. This narrows the unauthenticated path. It does not fix the flaw, and it breaks anything that relies on anonymous access, so treat it as a stopgap measured in hours.

4. Back up first. The backup command does not include your configuration and secrets file, so copy those separately and keep them somewhere safe.

   sudo gitlab-backup create
   sudo cp /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb /secure/backup/location/
   

5. Upgrade to the fixed patch on your current minor line. A patch within the same minor version does not need upgrade stops.

   # Debian and Ubuntu
   sudo apt-get update
   sudo apt-get install gitlab-ee=19.5.1-ee.0     # or gitlab-ce=19.5.1-ce.0
   
   # RHEL family: find the exact package name, then install it
   sudo dnf list gitlab-ee --showduplicates | grep 19.5.1
   
   # Docker: pull the fixed tag and recreate the container
   docker pull gitlab/gitlab-ee:19.5.1-ee.0
   

   Swap 19.5.1 for 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13 as needed.

6. Plan for downtime on single node servers. GitLab says this release includes database migrations, with regular migrations in 19.4.3 and 19.3.6 and post-deploy migrations in 19.4.3. Single node instances will be down while migrations run. Multi-node installs can use GitLab's zero downtime procedure.

7. Verify.

   sudo gitlab-ctl status
   sudo gitlab-rake gitlab:check SANITIZE=true
   sudo gitlab-rake gitlab:background_migrations:list   # 18.9 and later
   

   Then confirm the version again, from the API or the Help page.

8. Look back at the logs. GitLab's two detections are the best starting point. The Onigmo rule reads the Puma worker log; the Org mode rule reads the Rails exceptions log.

   sudo grep -c "\[BUG\]" /var/log/gitlab/puma/puma_stderr.log
   sudo grep -i "OtherMarkup" /var/log/gitlab/gitlab-rails/exceptions_json.log | grep -c "Timeout"
   

   A hit is a reason to investigate, not proof. A clean result is not proof either. GitLab's write-up says a successful exploit may not crash the worker and may leave no Rails log entry. Preserve logs before you restart anything if you see hits.

Upgrade paths for older versions

If you are on 18.10 or older, there is no fix on your line. GitLab requires you to stop at specific versions, let background migrations finish at each stop, and use the latest patch of each stop. Its current required stops include 18.2, 18.5, 18.8 and 18.11 in the 18 series, and 17.11.7, 17.8.7, 17.5.5 and 17.3.7 in the 17 series, with some conditional stops for large instances.

These are examples. Run your exact version through GitLab Support's Upgrade Path tool before you start, because conditional stops depend on your data. Between each step, wait for background migrations to finish.

sudo gitlab-rake gitlab:background_migrations:wait

A multi-hop upgrade on a large instance can take a day, so reduce exposure (step 3) while it runs.

What to rotate if the server may have been reached

If your detections fire, or an affected instance had public projects and was internet facing, and you cannot rule out access, assume everything the GitLab application user could read was exposed. GitLab's detection guidance lists the secrets in gitlab-secrets.json, all CI/CD variables, all runner tokens and all access tokens. Its general incident guidance adds audit event review, a review of every user including root, and the credentials inventory.

Order matters. Rotate after the server is patched or rebuilt, otherwise an attacker still on the box reads the new values.

1. Patch or rebuild first. GitLab's incident guidance says to save server state and logs to a write-once location, look for unknown processes and open ports, and rebuild from a known good backup or from scratch if you suspect compromise.

2. Runner authentication tokens. List every runner, then reset each token. The runner stops working until its config.toml has the new token, so coordinate with whoever owns the runner hosts.

   curl --header "PRIVATE-TOKEN: $ADMIN_TOKEN" \
     "https://gitlab.example.com/api/v4/runners/all?per_page=100"
   
   curl --request POST --header "PRIVATE-TOKEN: $ADMIN_TOKEN" \
     "https://gitlab.example.com/api/v4/runners/RUNNER_ID/reset_authentication_token"
   

   Legacy registration tokens are disabled by default from GitLab 17.0. If you re-enabled them, reset those as well.

3. CI/CD variables. Rotate the real secret at its source (the cloud key, the registry password, the database credential), then update the variable in GitLab. Changing only the GitLab copy leaves the old value valid wherever it is accepted. Do this at instance, group and project level.

4. Deploy keys and deploy tokens. Deploy keys are SSH keys with read or write access to repositories, and deploy tokens use the gldt- prefix. Remove and reissue them, starting with keys that have write access.

5. Personal, project and group access tokens. Use the rotate endpoints for tokens you keep and revoke the rest. Prioritise admin users and tokens with api or write_repository scope.

6. Everything else. GitLab's token overview also lists trigger, feed, incoming email and Kubernetes agent tokens, and OAuth application secrets. Webhook secrets and integration credentials live in the database too.

7. gitlab-secrets.json. Some values in this file encrypt data in GitLab's database, including CI variables. Changing them without the documented process can make that data unreadable. Plan this step with GitLab's documentation or support rather than editing the file by hand.

8. Downstream. Anything your pipelines could deploy to should be reviewed for changes made during the exposure window. A compromised GitLab is a compromised build system, and the incident response playbook for a compromised dependency applies: work out what was built, where it went, and rebuild from known good sources. Our post on incident response for a compromised dependency covers that part.

What would have helped

None of this is a comment on any particular organisation. These are practices any team running self-managed GitLab can adopt, and they echo the lessons in our roundup of October 2026 incidents.

Patch on GitLab's schedule, not yours. Scheduled patch releases land on the second and fourth Wednesdays. Put a standing maintenance window right after each one. Teams on the latest patch of a recent minor apply a critical fix in one step; teams two years behind face a multi-hop upgrade while the clock runs.

Stay within a supported minor. This fix was backported to seven lines. Anything older than 18.11 got nothing. Staying inside the supported window is the difference between a patch and a project.

Keep an inventory of GitLab instances and their versions. Runner configs are a good way to find instances nobody listed.

Treat public projects as internet exposure. An instance with public projects accepts anonymous input. Review which projects truly need to be public.

Keep CI secrets short-lived and scoped. Long-lived cloud keys in CI/CD variables are the most valuable thing on a GitLab server. Short-lived credentials issued per job through OIDC federation, protected and masked variables, and protected branches for deploy jobs all reduce what a server compromise yields.

Ship logs off the box. Both GitLab detections depend on logs you may not collect by default, including puma_stderr.log. If logs live only on the server, an attacker with code execution can edit them.

Practise the restore. A tested backup plus a copy of gitlab-secrets.json means a rebuild is a plan, not a hope.

Where Safeguard fits

Safeguard does not patch your GitLab server, detect exploitation of it, or rotate your tokens. Those steps are yours, using GitLab's guidance above. Here is where it does help.

• Inventory what you build and run. safeguard scan --dir . scans a repository, safeguard scan --image scans a container image, and safeguard scan --sbom scans an SBOM file, with JSON results under ./output. If you run GitLab or your runners from container images, you can scan those images to see their components. Whether a GitLab application advisory is matched depends on the vulnerability data, so still confirm your GitLab version against the table in this post.
• Find what a compromised build system touched. The platform shows which projects contain a given component and version. After a CI incident, that helps you list what was built from which images and dependencies, and what needs rebuilding. Our post on using SBOMs in incident response walks through that query.
• Prioritise. Vulnerability matching against vulnerability databases, with reachability analysis, helps you separate what is exploitable from the long tail in the images your pipelines produce.
• Gate rebuilds. Policies and gates evaluated in the platform, and safeguard exec in CI, can stop a rebuilt artifact from shipping if it pulls a known vulnerable component.
• Do the change work with approval. The Safeguard CLI's assistant can run commands and edit files with your approval. You can ask it to check the GitLab version on a host, draft the upgrade steps for your branch, or bump base image tags in your runner images. Set /permissions to Ask or Strict for server work so every command waits for you. The desktop and phone apps can send that work to a computer running the CLI and let you approve each command.

Zero-Day Discovery and Gold

Two Safeguard capabilities are about finding and fixing flaws in components earlier.

• Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. A self-managed GitLab server ships as an OS package or container image, which is outside that scope.
• Gold Open Source at gold.safeguard.sh is free with no login: searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action.
• Gold Registry at registry.safeguard.sh is the paid tier: hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages. An artifact loses its badge if it regresses.

The habit they support applies to the images your runners and pipelines use, not to the GitLab server itself: pull patched, signed components from a curated source, and be able to rebuild and redeploy quickly when an advisory lands.

Common mistakes

Assuming the 12 October patch covered it. It did not. 19.4.2, 19.3.5 and 19.2.8 fix CVE-2026-97229 and are still affected by CVE-2026-110264.

Patching production and forgetting the rest. Geo secondaries, DR replicas and test servers are often on older versions and less monitored.

Skipping upgrade stops. Jumping from an old version straight to 18.11.13 can fail mid-migration. Follow the Upgrade Path tool and let background migrations finish.

Rotating before rebuilding. If an attacker is still on the server, they read the new secrets as soon as you save them.

Rotating only in GitLab. Updating a CI/CD variable's value does not revoke the old cloud key. Revoke at the source.

Reading a quiet log as all clear. GitLab says a successful exploit may be silent. A clean detection result lowers risk; it does not prove anything.

Treating restricted visibility as the fix. It is a stopgap. Upgrade.

FAQ

Is CVE-2026-110264 being exploited?

GitLab's advisory does not say it is. SecurityOnline reported no confirmed exploitation and no public proof of concept on 21 October, Cybersecurity News said the same on 22 October, and Konfirmity reported it was not in CISA KEV. GitLab will publish the technical issue in about 90 days, and a CVSS 10.0 flaw in a product this widely deployed draws research attention. Patch now rather than waiting for the status to change.

Do I need to do anything on GitLab.com or GitLab Dedicated?

Not for this CVE. GitLab says GitLab.com runs the patched version and Dedicated tenants on 19.3.5-internal0, 19.4.2-internal0 or later already have the fixes. You may still want to review your own tokens and runners as routine hygiene, but there is no upgrade to do.

I patched on 12 October. Am I covered?

No. That release fixed CVE-2026-97229. CVE-2026-110264 is a separate flaw and needs the 21 October builds: 19.4.3, 19.3.6 or 19.2.9 for those lines.

Is there a workaround if I cannot upgrade today?

GitLab's advisory lists none. Its detection write-up names reducing public project visibility as an interim measure, which narrows the unauthenticated path. Combine that with restricting network access to the instance, and upgrade as soon as you can.

Are GitLab Runners affected?

The advisory is about the GitLab server (CE and EE), not GitLab Runner. Runners matter because of what they hold. If the server may have been reached, reset every runner authentication token and review what your runners can access.

What about versions older than 18.11?

They are affected back to 7.0 and have no patch on their own line. You must upgrade through GitLab's required stops to at least 18.11.13. Use the Upgrade Path tool.

When will full details be public?

GitLab says it publishes the issue for each vulnerability on its tracker 90 days after the patch release, so around mid January 2027.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These are real product sessions on other examples; none shows this GitLab incident.

The CLI demo shows the assistant fixing a lodash CVE in a repository: it reads the finding, asks before each command, edits package.json, runs install and tests with approval, and pushes nothing. For CVE-2026-110264, the same flow applies to your runner images and build repos after a GitLab incident: scan them, ask the assistant to bump base image tags or check the GitLab version on an admin host, and approve each command yourself.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a request for work on the computer, a folder choice, and an Approve or Deny decision on each command and file edit, ending with an upgrade done and tests passing. For a GitLab patch, you would point it at the repo that holds your GitLab Helm values or Docker Compose file and ask it to change the image tag to the fixed build, approving each edit.

Click through it at your own pace, or open it full screen.

The mobile demo shows a real Android session that sends work to a computer running the CLI and approves a command on the phone with Allow once, Allow for turn or Deny. A critical GitLab patch often lands outside working hours; this is how an on call engineer can approve a version check or a token reset command from a phone without handing the assistant open permission.

Click through it at your own pace, or open it full screen.

To try it on your own systems, download Safeguard and read the CLI documentation.

Quick check

Sources

• 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
• GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8
• GitLab Security detection: Org mode render error burst
• GitLab Security detection: Onigmo native worker crash
• GitLab Docs: Upgrade paths
• GitLab Docs: Background migrations
• GitLab Docs: Responding to security incidents
• GitLab Docs: Runners API
• GitLab Docs: GitLab token overview
• CISA Known Exploited Vulnerabilities catalog
• SecurityOnline: GitLab Critical Patch Release fixes 10.0 CVSS remote code execution flaw
• Cybersecurity News: 12-year-old GitLab vulnerability allows remote code execution
• Konfirmity: GitLab CVE-2026-110264 fixed versions

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.