GitLab Vulnerability CVE-2026-97229 Is Being Exploited: Why 19.4.2 Is Not Enough

A critical GitLab vulnerability, CVE-2026-97229, is being exploited. CISA added it to its Known Exploited Vulnerabilities (KEV) catalog on October 29, 2026. GitLab says the flaw lets an attacker with no account run code on a self-managed GitLab server. The attack uses a crafted regular expression in a CI/CD configuration.

GitLab fixed it on October 12. Nine days later, it fixed a closely related bug in the same regex engine, CVE-2026-110264. A server that stopped at the October 12 versions still carries that second GitLab vulnerability. Agencies and university web teams that host GitLab for site code and deploys should check their version now.

The short version: if you run self-managed GitLab, upgrade to the latest patch release in your version line today. As of November 2, 2026, that is 19.5.3, 19.4.5, 19.3.7, 19.2.10, 19.1.10, 19.0.11 or 18.11.14. GitLab.com and GitLab Dedicated customers do not need to patch the server. If your instance was open to the internet on an affected version, check for compromise. Then plan to rotate CI/CD secrets.

This post covers each advisory, the affected versions, how to check your server, and the steps after patching. If CVE numbers and scores are new to you, start with our guide to what a CVE is.

What the GitLab vulnerability does

GitLab’s October 12 critical patch release describes CVE-2026-97229 as an integer overflow in the CI/CD regular expression compiler. GitLab says it "could have allowed an unauthenticated user to execute arbitrary code on the GitLab server." GitLab blames "insufficient regular expression validation" for the bug.

In plain terms, GitLab lets CI/CD files contain regular expressions, for example in rules that decide when a job runs. Ruby’s notes on the fix describe an overflow in the compiled pattern size. A carefully built pattern triggers that overflow, and GitLab says the result can be code running on the server.

GitLab scored it CVSS 10.0, the maximum. The vector says it works over the network with no privileges and no user action. It also changes scope, so the damage can reach beyond the buggy component. Our guide on how to read a CVSS score explains each part of that vector.

GitLab credits a researcher named joaxcar, who reported it through GitLab’s HackerOne bug bounty program.

Why CISA’s KEV listing matters

CISA’s October 29 alert says CISA added this GitLab vulnerability to the catalog "based on evidence of active exploitation." The same alert added a Cisco firewall flaw.

A KEV listing means someone is already exploiting the bug. CISA’s catalog entry gave US federal civilian agencies a remediation due date of November 1, 2026, under Binding Operational Directive 26-04. That directive applies only to federal agencies, but CISA encourages every organization to prioritize KEV entries. The catalog lists known ransomware use for this entry as "Unknown."

CISA’s entry adds a note worth reading twice. It says other products "can potentially be affected by the same underlying Ruby/Onigmo Integer Overflow issue" as well. We cover that below.

We saw the same pattern last week with the GlobalProtect vulnerability. A patch exists, exploitation follows, and unpatched servers become targets.

The second regex flaw: why 19.4.2 is not enough

On October 21, GitLab published another critical patch release. Its top fix is CVE-2026-110264, an integer overflow in the regular expression compiler. It is also scored CVSS 10.0 and was also reported by joaxcar. GitLab says an unauthenticated user could run code on the server "due to integer overflow when compiling a specially crafted regular expression."

This second GitLab vulnerability reaches much further back. GitLab lists every version from 7.0 onward as affected until the fixed releases. Beyond its standard patch releases, GitLab backported the fix to the 18.11, 19.0, 19.1 and 19.2 lines.

As of November 2, CISA’s catalog lists only CVE-2026-97229, not CVE-2026-110264. That reflects what CISA has evidence of, not how risky the second bug is. A server patched on October 12 and left alone is still exposed to a CVSS 10 bug.

The October 29 release is the newest. Its security item, CVE-2026-111943, removes trust in eight compromised eMudhra intermediate certificates. It is not a regex fix, but it is the current patch level, so it is the sensible target.

The Ruby connection

Both GitLab bugs live in Ruby’s regular expression engine, which GitLab ships inside its packages. Ruby’s own October 23 security post lists four GitLab CVEs, including both of these. It says Ruby 4.0.9, 3.4.12 and 3.3.13 contain all the fixes.

Ruby’s post says the risk applies to software that builds regular expressions from untrusted input. In Ruby’s words, "Applications that only use regular expressions written by their own developers are not affected." It warns against relying on regex timeouts or length limits as protection.

For most of our readers, this matters in two places. Upgrading GitLab through its official packages brings GitLab’s patched Ruby with it. Other Ruby apps you host, such as a custom Rails tool, need their own Ruby update. That matters most if they build patterns from user input.

How to check if the GitLab vulnerability affects you

GitLab’s version documentation gives the simplest check. Sign in, go to the bottom of the left sidebar, and select Help, then Help. The version appears at the top of the page.

Then compare it with the table above. Act now if any of these is true:

• You are on 19.2, 19.3 or 19.4 below the October 12 fixes. You have the KEV-listed bug.
• You are on any version below the October 21 fixes. You have CVE-2026-110264.
• You run a version line older than 18.11. GitLab did not ship a fix for it. Plan an upgrade path to a supported line.

Remember that GitLab Runner is a separate install. The October 29 release asks self-hosted Runner users to update to Runner 19.5.1 for the certificate change.

How to patch the GitLab vulnerability safely

GitLab says these patches include database migrations. On a single-node install, expect downtime while migrations run, because GitLab cannot start until they finish. Multi-node setups can patch with no downtime if they follow GitLab’s zero-downtime upgrade steps.

A short plan for a small team:

1. Take a backup and a snapshot of the server.
2. Schedule a short maintenance window and tell developers pipelines will pause.
3. Upgrade to the latest patch release for your version line.
4. Confirm the new version on the Help page and run a test pipeline.

If the server faces the internet and you cannot patch today, reduce exposure first. Put it behind a VPN or an IP allow list until the upgrade is done. That is our suggestion, not a GitLab workaround. GitLab’s advisories do not list a mitigation other than upgrading.

Look for signs of the GitLab vulnerability being used

GitLab says it "has released six threat detections to support customers with self-managed instances" for CVE-2026-97229. The rules are linked from the advisory. Their names show what to look for:

• Onigmo native worker crash
• GraphQL CI lint hostile regexp
• CI regexp oversized non-ASCII path
• CI regexp guard rejection
• CI lint Workhorse worker crash
• CI lint scripted client error burst

The October 21 advisory adds two more detections for CVE-2026-110264. Unexpected worker crashes and bursts of CI lint errors are the common thread.

CISA’s alert says the directive also sets expectations for when agencies must check whether attackers got in before the patch was applied. The same logic fits any organization. If your server was exposed and unpatched after October 12, check it for this GitLab vulnerability being used.

What to do if the server was exposed

Code execution on a GitLab server means an attacker could read anything GitLab stores. That includes CI/CD variables, deploy keys, access tokens and the source of every project. These steps are our recommendations. GitLab does not list them.

• Rotate CI/CD variables that hold passwords, API keys and cloud credentials.
• Replace deploy keys and project, group and personal access tokens.
• Check for new admin accounts, new SSH keys and new runners you did not add.
• Review recent pipelines and commits for jobs nobody on your team started.

Build servers are a favorite target because they hold the keys to everything else. We saw the same pattern in the npm supply chain attack on CI credentials. Keeping secrets in managed variables makes rotation faster. Our env-var secrets migration checklist shows how.

Frequently Asked Questions