As of 30 October 2026, GitLab CVE-2026-97229 is a known-exploited vulnerability. CISA added it to its Known Exploited Vulnerabilities (KEV) catalog on 29 October with a due date of 1 November, a Sunday. It needs no account, scores CVSS 10.0, and lets an attacker run code on a self-managed GitLab server through a crafted regular expression in CI/CD configuration. The catch is that the fix in 19.4.2 isn't the version you should stop at. A fourth critical regexp CVE, CVE-2026-110264, was fixed one release later, and one upgrade can cover both. For the other releases we track, see our platform and language release notes.
What CISA listed
CISA's catalog entry classes the flaw as an integer overflow or wraparound (CWE-190). Its description says an unauthenticated user can execute arbitrary code on the server by submitting a specially crafted regular expression in CI/CD configuration, because of "insufficient regular expression validation". CISA marks ransomware use as "Unknown" and sets forensic triage to "Yes", which means it expects you to look for signs of compromise, not only patch.
The entry adds that other products can potentially be affected by the same underlying Ruby/Onigmo integer overflow in the regular expression compiler. That's the reason the Ruby section below exists.
The 1 November date binds US federal agencies. If you're not one, it's still the sensible benchmark: exploitation is confirmed and fixed releases exist.
Which GitLab versions are safe
GitLab's 19.4.2 patch notes list the affected branches as 19.2 before 19.2.8, 19.3 before 19.3.5 and 19.4 before 19.4.2. Fixes for CVE-2026-97229 are therefore 19.2.8, 19.3.5 and 19.4.2.
Don't stop there. GitLab's 19.5.1 notes fix CVE-2026-110264, another unauthenticated, CVSS 10.0 flaw in the same area, and it affects versions from 7.0. Our advice is to target the right-hand column below so one upgrade closes both.
| Branch | Fixes CVE-2026-97229 | Also fixes CVE-2026-110264 (target this) |
|---|---|---|
| 19.5 | Not listed as affected | 19.5.1 |
| 19.4 | 19.4.2 | 19.4.3 |
| 19.3 | 19.3.5 | 19.3.6 |
| 19.2 | 19.2.8 | 19.2.9 |
| 19.1 and older | Not listed as affected | 19.1.9, 19.0.10, 18.11.13 |
Instances on 19.1 or older aren't listed against CVE-2026-97229, but they are listed against the fourth CVE, so being outside the KEV CVE's affected range doesn't mean you're done. Instances older than 18.11 have no listed fix on their own branch: upgrade to a listed branch first, following GitLab's required upgrade stops. GitLab's notes say GitLab.com and GitLab Dedicated are already patched. Only self-managed instances need action.
Does an attacker need an account?
For CVE-2026-97229, no. GitLab's patch notes, the CVE record GitLab filed as the CVE Numbering Authority, and CISA's KEV entry all say "unauthenticated user". The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, which scores 10.0.
The two regexp CVEs in the September release were rated differently. CVE-2026-89078 and CVE-2026-93577 were described as needing an authenticated user (PR:L, 9.9). Same subsystem, different bug, different precondition. Our write-up of the September GitLab release with the two earlier regexp CVEs covers the authenticated pair, and that release fixed those two. This one is the unauthenticated follow-on.
Your own Ruby services may be exposed
The Ruby project published an advisory on 23 October, "Regexp fixes for GitLab CVEs". Fixed releases are Ruby 4.0.9, 3.4.12 and 3.3.13. Ruby hasn't requested CVE IDs of its own so far, so you track the issue under GitLab's.
Your exposure depends on one thing: does the app compile regular expressions from attacker-controlled strings? That means Regexp.new, Regexp.union, Regexp.compile or interpolation such as /#{input}/ with untrusted input. Regular expressions you wrote yourself aren't affected. Two defences that people reach for don't help, according to the advisory: Regexp.timeout doesn't protect, and length limits aren't reliable.
| GitLab CVE | Ruby 4.0 | Ruby 3.4 | Ruby 3.3 |
|---|---|---|---|
| CVE-2026-89078 | 4.0.0 | 3.4.12 | 3.3.13 |
| CVE-2026-93577 | 4.0.8 | 3.4.12 | 3.3.13 |
| CVE-2026-97229 | 4.0.8 | 3.4.12 | 3.3.13 |
| CVE-2026-110264 | 4.0.9 | 3.4.12 | 3.3.13 |
On Ruby 4.0, aim for 4.0.9 so one upgrade covers all four. Ruby 3.3 is in security maintenance, and the advisory says 3.3.13 includes these fixes as an exception because GitLab assigned CVEs to them. If you can't upgrade the runtime yet, the stopgap is to stop compiling untrusted input as a pattern. Check search boxes, filter builders and admin "match rule" fields first, since those are where user text most often reaches Regexp.new.
If you were unpatched while the fix was public: triage
CISA's forensic triage flag is the reason to treat this as more than a version bump. The following is our advice, not CISA's or GitLab's.
GitLab lists six threat detections for CVE-2026-97229 in its 19.4.2 notes (self-managed only). The same six first appeared in the 19.4.1 notes in September, under CVE-2026-93577: Onigmo native worker crash, Graphql cilint hostile regexp, CI regexp oversized non-ASCII path, CI regexp guard rejection, CI lint workhorse worker crash, and CI lint scripted client error burst. Search your logs for them.
Then, if the instance was internet-reachable on an affected version, assume anything a pipeline can read might have been read. Rotate in this order:
- CI/CD variables, especially cloud credentials and deploy secrets.
- Runner registration tokens.
- Deploy keys and personal, project and group access tokens.
Review recent pipeline and configuration changes for anything nobody can explain, and check the runner hosts themselves. Exposure before the fix was public is unknown, so none of this proves a compromise. It's the cost of not knowing.
For another example of the same inventory-and-owner drill, see PHP2Shell on the KEV list and Brotli KEV fixes for Node.js and .NET.
What this means for who owns GitLab patching
The decision is who is accountable for patching self-hosted GitLab inside a KEV window, on a weekend, and whether it should stay self-hosted at all. GitLab says GitLab.com and Dedicated were patched already. A self-managed instance gets patched when a named person does it.
Our judgment: if nobody on your team can say today which GitLab version you run and who upgrades it, either assign that now or price the move to a managed offering. Ask any agency or vendor that runs your GitLab or Ruby apps to confirm versions in writing today, not next week. The questions overlap with answering the contractor security questions, which is the next place to go.
FAQ
Is CVE-2026-97229 unauthenticated?
Yes. GitLab, the CVE record and CISA all describe it as exploitable by an unauthenticated user, with a CVSS 10.0 vector of PR:N. The earlier September pair, CVE-2026-89078 and CVE-2026-93577, were rated as needing authentication.
Is GitLab.com affected?
GitLab says GitLab.com and GitLab Dedicated are already patched. Self-managed instances need to upgrade themselves.
Which version should I run?
The fixed versions for CVE-2026-97229 are 19.2.8, 19.3.5 and 19.4.2. Go one patch higher, to 19.2.9, 19.3.6, 19.4.3 or 19.5.1 or later, so CVE-2026-110264 is closed in the same upgrade. Instances on 19.1 and older branches go to 19.1.9, 19.0.10 or 18.11.13.
Does my Rails app need Ruby 4.0.9?
Only if it runs Ruby 4.0 and compiles regular expressions from untrusted input. The matching fixes on older lines are 3.4.12 and 3.3.13. If your code only uses regular expressions you wrote yourself, the advisory says you're not affected.
Does Regexp.timeout help?
No. Ruby's advisory says it doesn't protect against this issue, and neither do length limits.
Do I need to rotate secrets?
If your instance was reachable and unpatched, we'd rotate CI/CD variables, runner tokens and deploy keys. CISA flags forensic triage for this entry, and a pipeline can read every secret it's given. That's our advice, not an official requirement.