How to Upgrade GitLab for CVE-2026-110264, the CVSS 10 Critical Patch
GitLab shipped an out-of-band fix for an unauthenticated code execution bug that reaches back to version 7.0. Here is how to pick your target version, upgrade safely, and check logs afterward.
On this page 9 sections
To fix CVE-2026-110264, upgrade your self-managed GitLab to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, or 18.11.13, whichever matches your release line. The flaw scores CVSS 10.0, needs no login, and has no documented workaround. GitLab.com and GitLab Dedicated tenants on current builds are already patched, so only self-managed installs need action.
Backtrace covers the DevOps tooling that keeps pipelines running, and a source code host with remote code execution is as serious as it gets. GitLab announced the critical patch on October 21, 2026. This guide is for administrators of self-managed CE and EE instances who need a clear order of operations.
What Is CVE-2026-110264 and Who Is Affected?
It is an integer overflow in the regular expression compiler. Under certain conditions, an unauthenticated user can execute arbitrary code on the GitLab server. It was reported through HackerOne and rated 10.0, the maximum on the CVSS scale.
The affected range is huge. According to GitLab's patch release notice, all CE and EE versions from 7.0 before 18.11.13 are affected, along with 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.
GitLab.com already runs the patched version. GitLab Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 and later already include the fix. The exposure is limited to self-managed installs, which means your team owns the response.
Which Version Should You Upgrade To?
Pick the fixed patch in your current minor line when you can, because it carries the smallest change. If your instance is far behind, plan an upgrade path instead of jumping straight to the newest release.
This table maps each release line to its fixed version.
| Your version line | Upgrade to |
|---|---|
| 18.11.x and older, down to 7.0 | 18.11.13 or a supported newer line |
| 19.0.x | 19.0.10 |
| 19.1.x | 19.1.9 |
| 19.2.x | 19.2.9 |
| 19.3.x | 19.3.6 |
| 19.4.x | 19.4.3 |
| 19.5.x | 19.5.1 |
Instances older than 18.11 cannot jump straight to a fixed build. GitLab publishes a required stop sequence in its upgrade paths documentation, and skipping a stop can break database migrations. Check it before you schedule the window, and note that very old instances may need several hops.
How Do You Run the Upgrade With Minimal Risk?
Back up, read the upgrade notes, and then upgrade in a window with a rollback plan. The patch includes database migrations, so the order matters more than speed.
Work through these steps in order.
- Take a full backup of the database, repositories, and configuration, and store a copy off the host.
- Read the upgrade notes for your target version, including the migration notes for 19.4.3 and 19.3.6.
- Pick single-node or zero-downtime. Single-node instances will have downtime because migrations must finish before GitLab starts. Multi-node instances can follow the zero-downtime upgrade procedure.
- Upgrade the package or image, then wait for migrations, including the post-deploy migration in 19.4.3, to finish.
- Confirm the version in the admin area and run a test pipeline end to end.
Announce the window to developers early. A CI outage is easier to accept when teams know it is a security fix with a start and end time. If you also run runners on separate hosts, update them after the main instance so versions stay compatible.
If you are still comparing platforms, our GitHub Actions vs. GitLab CI comparison covers the maintenance burden of running your own instance versus using a hosted service. This week is a reminder that self-hosting means owning the patch calendar.
Why Does a Regex Compiler Bug Lead to Code Execution?
An integer overflow happens when a number grows past the size its storage can hold and wraps around. In a regular expression compiler, that number is often a buffer size or an offset. If the compiler allocates too little memory and then writes more, the extra bytes land in places the attacker may influence.
That is a classic memory corruption pattern, and it explains the severity. A server that compiles a pattern from attacker-influenced input can be pushed into corrupting its own memory. GitLab's detection names point at the Onigmo regex engine and Org-mode rendering, which suggests the trigger sits in how certain file types are processed.
The lesson reaches beyond GitLab. Regex engines are written in memory-unsafe languages in many stacks, and they process input that users control. When you assess your own exposure, ask which services parse untrusted text, and make sure those services run with the least access possible.
What Should You Prepare Before the Maintenance Window?
A short pre-flight list prevents most upgrade surprises. Spend an hour on it before you touch production, because a failed migration at midnight is far more costly than the hour.
- Confirm your current version and which row of the table applies to you.
- Verify that the backup restores in a test environment, not only that it completes.
- Check free disk space, since migrations and package downloads need headroom.
- List external integrations, such as runners, webhooks, and SSO, so you can test each one afterward.
- Name one person who can approve a rollback if the upgrade stalls.
Test the same steps on a staging copy when you have one. A restored backup on a spare machine gives you real timing for the migrations, which tells you how long production downtime will last. Share that number with developers before the window opens.
What Else Did the Patch Release Fix?
The same release fixes two high-severity issues alongside the critical one. CVE-2026-15723 is an OmniAuth-to-LDAP account takeover that applies when SAML and LDAP auto-linking are both enabled, rated CVSS 8.2. CVE-2026-112212 is OAuth and OIDC discovery cache poisoning, rated 7.5.
If your instance uses SAML with LDAP, the first one matters in its own right. It is easy to focus on the CVSS 10 and miss that a second fix in the same release closes an account takeover path. Upgrading once covers both, along with a long list of medium and lower issues in access control, authorization, and credential exposure.
This is a good moment to review your authentication setup. Disable features you do not use, such as unused auto-linking options. Every enabled integration is part of your attack surface.
How Do You Check Logs After Patching?
Use GitLab's detections and then look for odd behavior around the time of exposure. GitLab security released two threat detections for self-managed instances, named Onigmo native worker crash and Org mode render error burst.
Both point at the regex engine and the rendering of Org-mode files, which are the areas touched by this flaw. Look for repeated worker crashes, bursts of render errors, and unexpected child processes spawned by GitLab services. GitLab's advisory reports no attacks so far, but treat that as a snapshot, not a guarantee. GitLab makes issue reports public 90 days after a fix, so full technical details are expected later.
If the logs look wrong, assume the worst. Isolate the host, preserve evidence, and rotate every secret stored in the instance. That list is long: CI/CD variables, deploy keys, runner tokens, personal access tokens, and integration credentials. Our incident response runbook checklist gives a structure for the first hours, and the same pattern applies in our PHP2Shell patch guide from earlier this week.
How Can You Shrink the Exposure Window Next Time?
Subscribe to GitLab's security release announcements and assign an owner to read them. A patch notice that sits unread in a shared inbox is the most common reason a critical fix waits for days. One named person and one backup is enough.
Automate what you can. Many teams run self-managed GitLab from an official package or container image, which makes a version bump a single change in configuration management. Rehearse that change on staging each month, so the real upgrade feels routine. A rehearsed upgrade also tells you early when a migration needs extra time.
Finally, keep the instance off the open internet where possible. Developers can reach a VPN-only GitLab as easily as a public one, and unauthenticated bugs matter far less when attackers cannot connect. If external contributors need access, put a reverse proxy with allowlisting in front, and log every request that reaches it.
Conclusion: Patch First, Then Harden
The practical answer is to find your release line in the table, back up, and upgrade to the matching fixed version today. Verify with a test pipeline and review the two published detections.
Next, reduce how reachable the instance is. Put it behind a VPN or an IP allowlist where your team's workflow allows it, because an unauthenticated flaw is only dangerous to hosts the attacker can reach. At Backtrace, we recommend turning this week's scramble into a standing monthly patch window, so the next critical fix is a routine upgrade rather than an emergency.
