October 30, 2026

Two Critical GitLab Flaws, Not One: Why the October 12 Fix Is Not Enough

A man with glasses writing code at a home office desk with a laptop and a large monitor

A GitLab vulnerability (CVE-2026-97229) was added to the US CISA’s Known Exploited Vulnerabilities (KEV) catalog on October 29, 2026. The deadline for US federal agencies is November 1, and the entry is marked “forensic triage required”, meaning the systems should be checked for signs of compromise (I checked the data in CISA’s KEV directly).

This article is for companies that run GitLab on their own servers, not GitLab.com. It is built on primary sources and separates what is confirmed from what is not. The information is current as of October 30, 2026. Sources are given next to each statement. For the VPNs, mail gateways and other devices that entered KEV this month, see this month’s confirmed-exploited edge devices.

Key points

The flaw is in the way GitLab handles regular expressions written in CI/CD configuration. A crafted expression lets an unauthenticated attacker run code on the server. GitLab rates it CVSS 10.0, the maximum (GitLab).
A second flaw of the same kind, also rated 10.0, came out nine days later. These are CVE-2026-97229 (October 12) and CVE-2026-110264 (October 21). The October 12 fixes (19.4.2, 19.3.5, 19.2.8) remain affected by the second one (GitLab).
To be safe, move to the October 21 fixes (19.5.1, 19.4.3, 19.3.6, 19.2.9 and so on) or later.
CISA listed only the first one, CVE-2026-97229. CVE-2026-110264 is not in CISA’s data as of October 29.
The real fix is in Ruby’s regular expression engine (Onigmo), not in GitLab’s own code. GitLab’s official packages ship a patched Ruby. A self-built image with a standard Ruby stays vulnerable until Ruby is fixed too.
Who exploited it, where and how often has not been published. The one affected party that has published a timeline is Alpine Linux.

What happened

Date (2026)	Event	Source
October 12	GitLab releases fixes for CVE-2026-97229 (19.4.2, 19.3.5, 19.2.8). Severity 10.0. Found by joaxcar through HackerOne	GitLab
October 13	Rapid7 publishes an advisory, and adds a technical analysis later (October 16)	Rapid7
October 20–21	An attacker registers an account on Alpine Linux’s self-hosted GitLab (20th), then attacks in earnest the next day	Alpine Linux
October 21	GitLab releases fixes for CVE-2026-110264 (19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13). Severity 10.0. Every version from 7.0 is affected	GitLab
October 23	Ruby releases fixes (4.0.9, 3.4.12, 3.3.13)	Ruby
October 26–28	Alpine finds its GitLab was still vulnerable after updating (26th) and rebuilds the server (27th–28th)	Alpine Linux
October 29	CISA adds CVE-2026-97229 to KEV	CISA’s KEV data

There are four CVEs in total

According to Ruby’s advisory, GitLab reported three bugs in Ruby’s regular expression engine, and GitLab issued four CVEs for them (Ruby).

GitLab CVE	Bug in Ruby	First Ruby versions with the fix
CVE-2026-89078	Double free when parsing fails	4.0.0, 3.4.12, 3.3.13
CVE-2026-93577, CVE-2026-97229	Integer overflow in the size of a compiled pattern	4.0.8, 3.4.12, 3.3.13
CVE-2026-110264	Overflow of internal IDs in a pattern with many repeats	4.0.9, 3.4.12, 3.3.13

Ruby 4.0.8 has the fix for CVE-2026-97229 but not for CVE-2026-110264. For Ruby 3.4 and 3.3, the first versions with these fixes are 3.4.12 and 3.3.13. Ruby 3.2 and earlier get no fix (Ruby).

Ruby has not assigned CVEs of its own for these, at least for now. A scanner that matches CVEs against the Ruby version alone can miss them. Ruby recommends tracking the GitLab CVE numbers (Ruby).

A flaw in a component that a product bundles does not show up in the product’s version number. The Brotli flaw from the same week was also a problem in a component bundled by Node.js, .NET and others.

What is affected

Self-managed GitLab (CE and EE). CVE-2026-97229 affects 19.2 to 19.4 before the fixes. CVE-2026-110264 affects every version from 7.0 (GitLab).
GitLab.com is already patched. GitLab Dedicated runs patched internal releases (GitLab).
Outside GitLab, any Ruby application that builds a regular expression from a string an attacker controls may be affected. Applications that only use expressions written by their own developers are not. CISA also notes that other products can be affected by the same underlying flaw (Ruby, CISA’s KEV data).

GitLab’s rating says no authentication is needed. In Rapid7’s testing, though, the attacker has to be able to put a malicious CI configuration into a public project first. On an instance where anyone can register, that condition disappears (Rapid7).

How firm is the evidence of exploitation

Item	What it says	Confidence
CISA KEV listing	October 29. CVE-2026-97229 only. Due November 1. Forensic triage required. No attacker or target named	Primary (CISA’s KEV data)
GitLab’s notices	The October 12 and October 21 notices do not say exploitation has been observed. Detection rules are published	Primary (GitLab 10/12, GitLab 10/21)
Actual attack reported	On Alpine Linux’s own GitLab, worker processes crashed 8 times on October 21, and in 4 of them the attack got part of the way. No evidence of success was found	Primary (the affected party’s own report; Alpine Linux)
Public exploit	Rapid7 reproduced code execution on the official 19.4.1 image. It did not work on the patched 19.4.2	Secondary (Rapid7)
Exploitation of CVE-2026-110264	I could not find a primary source saying it has been exploited	Not confirmed

In short: CISA lists CVE-2026-97229 as exploited and the affected party reports an attack, while CVE-2026-110264 is newer and I could not confirm exploitation. Even so, the first fixes do not cover the second flaw, so it is safer to fix both at once.

What the Alpine Linux case shows

Alpine Linux runs its own GitLab. It was attacked, and it published its account (Alpine Linux).

On October 13 it updated to 19.3.4 thinking it was the fix (the fix was in 19.3.5)
On October 22 it updated to 19.3.6, but its own image was still not fixed
On October 26 it noticed the instance was still vulnerable, rebuilt the server on the 27th, and by the 28th had reset passwords and replaced secret keys
A successful attack leaves no trace in the logs, so it could not tell whether the attack had worked. It treated the instance as compromised

Alpine explains the cause this way: the fix is not in GitLab’s own code but in a patch to the Ruby that GitLab bundles. GitLab’s official packages have that patch. Alpine built its image with a standard Ruby, so updating GitLab did not fix it. Ruby’s advisory also says GitLab fixed these in its own releases by patching the Ruby it ships (Ruby).

Alpine’s attacker registered an account, probed, then attacked in earnest, and also downloaded the container image. Alpine thinks the attacker may have been tuning the attack to Alpine’s build.

What to do now

1. Check your GitLab version and how it was installed

For an Omnibus install, this shows the GitLab version:

sudo gitlab-rake gitlab:env:info

The target versions:

Series	Minimum fixed version
19.5	19.5.1
19.4	19.4.3
19.3	19.3.6
19.2	19.2.9
19.1	19.1.9
19.0	19.0.10
18.11	18.11.13

Series not on the list have no fixed release, so you need to move up to one on the list (source: GitLab). If you stopped at the October 12 fixes (19.4.2, 19.3.5, 19.2.8), update again.

2. How you installed it decides what to do about Ruby

With GitLab’s official packages or official images, updating GitLab to the versions above also fixes the bundled Ruby
If you build your own image or use the OS’s standard Ruby, move Ruby to 3.3.13, 3.4.12, 4.0.9 or later. Updating GitLab alone does not fix it
Ruby 3.2 and earlier have no fix. Move to 3.4 or 4.0

3. Stopgaps if you cannot update

None of these makes you safe. They only buy time.

Restrict anonymous access to public projects
Stop untrusted users from creating or writing to public projects

Both only close the delivery path Rapid7 demonstrated. The flaw itself stays (Rapid7). GitLab’s notice offers no workaround.

4. Check for compromise

CISA marks this as requiring forensic triage. Before and after updating, check the following.

Whether GitLab workers have been crashing unusually, and whether 502 errors or failed CI jobs have suddenly increased (this is what happened mid-attack at Alpine)
Whether there are accounts or public projects you do not recognize
If your environment can use the detection rules GitLab publishes, turn them on. “Onigmo native worker crash” (worker crashes) is the central one (GitLab)
Whether you still have records of outbound connections and database connections. Alpine recommends keeping logs for longer than 14 days

A successful attack can leave no crash and no web log. If in doubt, consider what Alpine did: rebuild, reset passwords, replace secret keys. Alpine lists what could be taken if an attack succeeded: email addresses, password hashes, two-factor secrets, CI/CD variables, runner tokens, webhook credentials, private repositories and more.

What not to do

Do not stop at the October 12 fixes. The October 21 flaw is not fixed by them
Do not assume updating GitLab alone is enough. With your own Ruby or image, Ruby has to be fixed too
Do not trust a scanner result based on the Ruby version alone. Ruby has no CVEs of its own for this
Do not try exploit code you found online on production

What is not confirmed

CISA does not say who exploited this, where, or how many times. What the exploitation looked like is unknown
I could not find a primary source saying CVE-2026-110264 is being exploited. The name of one of GitLab’s detection rules suggests that rendering Org-format files is one way in, but the notice does not say so
Alpine’s account is inconsistent about which version carries the fix (the timeline says 19.3.5, while one passage says 19.3.4 lacked it). GitLab’s notice says the fixed version for CVE-2026-97229 is 19.3.5
Alpine’s checks cover commits up to October 22 and packages up to October 24. I could not confirm the results of extending the checks to October 27
I have not read GitLab’s notices for the first two CVEs (CVE-2026-89078, CVE-2026-93577). I rely on what Ruby’s advisory says