If your team hosts its own GitLab, the clock just got shorter. On 29 October 2026 CISA added CVE-2026-97229 to its Known Exploited Vulnerabilities (KEV) catalog and gave it a due date of 1 November 2026. GitLab fixed the flaw on 12 October 2026, so the patch has been available for more than two weeks. What changed is that exploitation is now on the record.
This guide is for founders, CTOs and whoever looks after GitLab. It has no exploit detail, only what you need to decide and act.
Self-hosted GitLab usually sits on servers like these, often with more internet exposure than its owners realise. Photo: NOIRLab/NSF/AURA/T. Slovinský, CC BY 4.0, via Wikimedia Commons
The short answer
CVE-2026-97229 is an integer overflow in GitLab's CI/CD regular expression compiler. GitLab rates it CVSS 10.0, the highest score, and says that under certain conditions it could let an unauthenticated user run code on the GitLab server using a crafted regular expression in a CI/CD configuration. It affects GitLab Community Edition and Enterprise Edition from 19.2 up to the fixed releases 19.2.8, 19.3.5 and 19.4.2.
CISA's catalog lists it as exploited. Its entry says the required action is to apply the vendor's mitigations, and it records the ransomware-campaign field as "Unknown". We did not find a public account of who is exploiting it or how, so treat any such claim as unconfirmed.
If you use GitLab.com, GitLab says it is already patched. If you run GitLab on your own server, upgrade now.
What the flaw is, in plain terms
GitLab lets people write rules in CI/CD configuration, and some of those rules use regular expressions, which are text-matching patterns. GitLab checks these patterns before using them. GitLab's advisory says the problem is "insufficient regular expression validation" in a component that compiles them. The Ruby project, whose regular expression engine GitLab uses, describes the underlying cause as a bug in how the size of a compiled pattern is calculated.
The flaw was reported by a researcher through GitLab's bug bounty program. A security firm, Rapid7, wrote on 13 October that it had reproduced code execution on an unpatched GitLab 19.4.1 image and that the patched 19.4.2 image was not affected. At that point it reported no confirmed attacks in the wild. The CISA listing on 29 October is what changed that picture.
Why "unauthenticated" needs a careful reading
GitLab's score reflects an attacker needing no account. Rapid7's testing added a practical detail: an attacker has to be able to place a malicious CI/CD configuration in a project on the server. On instances where visitors can register themselves and create public projects, that is easy. On instances where accounts are tightly controlled, it is harder.
This is why your settings matter as much as your version:
- Is new-user sign-up open, or does an admin approve accounts?
- Can ordinary users create public projects?
- Is the server reachable from the whole internet, or only from a VPN?
Rapid7 notes that restricting anonymous access and untrusted users' ability to create or write to public projects can reduce exposure to the route it demonstrated, but that these controls do not fix the flaw. Use them as a stopgap while you schedule the upgrade, not as a substitute.
Which versions to move to
| Your release line | Minimum fix for CVE-2026-97229 | Better target |
|---|---|---|
| 19.2 | 19.2.8 | 19.2.9 |
| 19.3 | 19.3.5 | 19.3.6 |
| 19.4 | 19.4.2 | 19.4.3 or 19.5.1 |
The "better target" column exists because GitLab shipped a second critical regular expression fix on 21 October 2026 for CVE-2026-110264, with fixed versions 19.5.1, 19.4.3, 19.3.6 and 19.2.9. Installing the latest patch for your line closes both with one maintenance window. We cover that second flaw in our CVE-2026-110264 guide.
If you are on 19.1 or older, the 19.2 notes do not list you as affected by this specific CVE, but you are likely missing other fixes, so plan an upgrade to a supported line anyway.
Plan for downtime
GitLab's 12 October notes say the patch release includes database migrations. On a single-node installation, GitLab cannot start until the migrations finish, so expect downtime. Multi-node setups that follow GitLab's zero-downtime upgrade procedure can avoid it. Pick a quiet window, take a backup first and tell the people who push code.
Check whether anyone got there first
Because CISA lists the flaw as exploited, patching alone is not the end. CISA's catalog entry also flags that forensic triage is expected for this entry, so look back as well as forward:
- GitLab published six threat detections for self-managed instances: a native worker crash, a hostile regular expression through the GraphQL CI lint, an oversized non-ASCII path, a guard rejection, a CI lint worker crash and a burst of scripted CI lint errors. Read the advisory to see how to look for them in your logs.
- Review recently created users, projects, personal access tokens, runners and CI/CD variables. Anything you do not recognise is a reason to dig further.
- If you find signs of compromise, rotate CI/CD secrets, deploy keys and runner tokens, because GitLab usually holds the keys to your production systems.
- Check outbound connections from the GitLab server. A code repository host rarely needs to talk to unfamiliar addresses.
If you cannot tell whether you were affected, treat the server as potentially exposed and take advice before restoring trust in it.
Not just GitLab: the Ruby angle
CISA's notes say other products can potentially be affected by the same underlying Ruby problem. On 23 October 2026 the Ruby project released 4.0.9, 3.4.12 and 3.3.13 with fixes for the regular expression bugs behind four GitLab CVEs, including this one. Ruby says the bugs are reached only when an application compiles a pattern from text that an attacker controls, for example through Regexp.new, Regexp.union or Regexp.compile. Applications that use only patterns written by their own developers are not affected.
Ruby also states that Regexp.timeout does not protect against these bugs, and that limiting pattern length is not a reliable defence. If your own software is written in Ruby, ask your developers one question: do we ever turn user-supplied text into a regular expression? If yes, upgrade Ruby and review that code. This is the same lesson as other platform flaws we have covered, such as the PHP2Shell runtime bug: the fix lives below your application code, so it arrives through updates.
What to do
- List every GitLab instance you run, including old test servers and installs a former vendor set up.
- Check each version and upgrade to the latest patch for its line (see the table above).
- Take a backup and schedule the downtime, since the patch includes database migrations.
- Turn off open sign-up and restrict public project creation until you have patched.
- Put GitLab behind a VPN or an IP allowlist if it does not need to be public.
- Review new users, tokens, runners and CI/CD variables for anything unexpected.
- Apply GitLab's threat detections to your logs and look back to 12 October.
- Rotate CI/CD secrets and runner tokens if you find anything suspicious.
- Ask developers whether any Ruby code builds patterns from user input, and upgrade Ruby if so.
- Subscribe to GitLab's patch notifications so the next release does not depend on reading the news.
Common mistakes to avoid
Assuming the fix is old news. A patch published on 12 October protects nobody until it is installed. The KEV listing exists because some servers were still unpatched.
Patching only to the minimum. Installing 19.4.2 fixes this CVE but leaves the 21 October critical fix undone. Go to the latest patch for your line.
Relying on settings alone. Closing sign-up helps, but Rapid7 says such controls do not remediate the compiler flaw.
Forgetting secrets. If a CI server is compromised, every token it can read is compromised. Rotating them is part of the response, not an optional extra.
Skipping backups. Migrations that fail halfway are rare, but a restore point turns a bad night into a short delay.
Why smaller teams should care
Small companies often run GitLab because it is free to self-host and holds source code, deployment keys and customer-facing configuration in one place. That makes it a high-value target and a single point of failure. A scheduled routine, such as the one in our website maintenance guide, turns advisories like this from emergencies into calendar items. If you do not have the time or the people for that, an outside team can own the updates for you.
Need help auditing or upgrading your GitLab, CI/CD or hosting setup? Talk to Susraj Tech.
Key takeaways
- CISA added CVE-2026-97229 to its exploited list on 29 October 2026, with a due date of 1 November 2026.
- GitLab fixed it on 12 October 2026 in 19.4.2, 19.3.5 and 19.2.8; the flaw is rated CVSS 10.0.
- Move to the latest patch for your line so the 21 October critical fix, CVE-2026-110264, is covered too.
- Sign-up and public-project settings change your exposure but do not replace patching.
- After patching, look back for signs of misuse and rotate secrets if anything looks wrong.
- Ruby applications that compile patterns from user input should upgrade to Ruby 4.0.9, 3.4.12 or 3.3.13.
Sources
- CISA Known Exploited Vulnerabilities catalog (entry for CVE-2026-97229, added 29 October 2026)
- GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8
- Ruby: Regexp compilation fixes related to GitLab's CVEs
- Rapid7: CVE-2026-97229, Critical Unauthenticated Remote Code Execution in GitLab
- Help Net Security: GitLab admins urged to patch critical RCE flaw
Last reviewed 29 October 2026. This article is general security information, not a guarantee of protection. Details may change as GitLab and CISA publish more information.
