GitLab CVE-2026-97229 Exploited: Patch Servers, Check Ruby

CISA lists GitLab's CVSS 10.0 flaw CVE-2026-97229 as exploited. If you host your own GitLab, upgrade now and make sure Ruby is patched too.

On 29 October 2026 (US time), the US Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-97229, a critical GitLab vulnerability rated CVSS 10.0, to its Known Exploited Vulnerabilities (KEV) catalog, based on evidence of active exploitation. If your company, your development team or your software vendor runs its own GitLab server, check the version today. There is one catch: on some installations, upgrading GitLab alone does not fix the bug.

What happened

GitLab released fixes on 12 October 2026. According to GitLab's advisory, the flaw is an integer overflow in the regular expression compiler used for CI/CD configuration. Under certain conditions, an unauthenticated user could run arbitrary code on the GitLab server with a specially crafted regular expression in a CI/CD configuration.

Affected: self-managed GitLab Community Edition (CE) and Enterprise Edition (EE) 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2.
Not affected: GitLab.com and GitLab Dedicated, which GitLab says were patched before the release was published.
Note: 19.3.4 does not contain the fix. The fixed 19.3 version is 19.3.5.

The underlying bug is in Onigmo, the regular expression engine built into Ruby. GitLab fixed it by patching the Ruby it bundles in its official packages and container images. The Ruby project shipped its own fix on 23 October in Ruby 3.3.13, 3.4.12 and 4.0.9.

A real attack attempt: Alpine Linux

On 28 October, the Alpine Linux project published a report on an attempt to exploit this flaw on its own GitLab server. A newly registered account sent crafted CI configurations on 20 and 21 October, crashing GitLab worker processes eight times. Alpine had upgraded to 19.3.4 by mistake, and its later upgrade to 19.3.6 still left the server exposed, because its container image used standard Ruby rather than GitLab's patched Ruby. Alpine found no evidence that the attack succeeded, but said it could not rule it out and noted that a successful exploit "would leave no crash and no trace in the web logs". It rebuilt the server, reset all passwords and replaced GitLab's secret keys.

Security firm Rapid7 reproduced code execution in its lab. In its tested method, the attacker first needs to commit a malicious .gitlab-ci.yml file to a public project. Rapid7 notes that on servers where anyone can sign up and create projects, this is easy to meet.

Why it matters to Hong Kong SMEs

Many web agencies, start-ups and in-house IT teams host GitLab on a cloud server to manage source code and CI/CD pipelines. A GitLab server often holds more than code. Alpine lists what could have been exposed if the attack had worked, including CI/CD variables, runner tokens, webhook and integration credentials, 2FA secrets and private repositories. CI/CD variables frequently contain cloud keys and deployment passwords, so a compromised GitLab server can lead to your production website and cloud accounts.

What to do now

Find out whether you run self-managed GitLab. Ask your developers or vendor. If you only use GitLab.com, no action is needed for this CVE.
Upgrade to the latest patch release for your version. The minimum fixed versions for this CVE are 19.4.2, 19.3.5 and 19.2.8. GitLab has since released further security updates (latest at the time of writing: 19.5.3, 19.4.5, 19.3.7, 19.2.10), including a fix for a second critical regular expression flaw, CVE-2026-110264, which affects a much wider range of versions. Plan for brief downtime on single-server installations.
Check Ruby if you do not use GitLab's official packages. If GitLab is built from source or in your own container image, you also need Ruby 3.3.13, 3.4.12, 4.0.9 or later.
Reduce exposure until patched. Turn off open sign-up, stop untrusted users creating or writing to public projects, restrict anonymous access, and consider putting GitLab behind a VPN or IP allowlist.
Look for warning signs. GitLab lists detections such as "Onigmo native worker crash" and "ci lint workhorse worker crash". Also check for unexpected new accounts and repeated worker crashes or 502 errors since mid-October.
If you were exposed, rotate secrets. If an internet-facing server ran a vulnerable version, consider rotating CI/CD variables, runner tokens, deploy keys, access tokens and any cloud credentials stored in GitLab, and enforce multi-factor authentication for all users.
Report incidents. If you suspect compromise, keep logs and contact HKCERT.

A regular, tested patch management process is the best defence against flaws like this one. Our cybersecurity and compliance team can review your exposure, and our managed support service can take on ongoing patching and monitoring.

Frequently asked questions

We use GitLab.com. Do we need to do anything?

Not for this CVE. GitLab says GitLab.com and GitLab Dedicated are already patched. Self-hosted GitLab Runners are a separate component, and GitLab's latest release asks Runner users to update for a different issue.

We upgraded GitLab. Are we safe?

Not necessarily. 19.4.2, 19.3.5 and 19.2.8 fix this CVE only. A second critical flaw, CVE-2026-110264 (CVSS 10.0), was fixed later in 19.5.1, 19.4.3, 19.3.6 and 19.2.9, so upgrade to the latest patch release for your version (19.5.3, 19.4.5, 19.3.7 or 19.2.10 at the time of writing). GitLab's official Linux packages and images include the fixed Ruby; if you use your own Ruby, check the Ruby version too. Alpine's experience shows the GitLab version number alone can be misleading.

Is this flaw being used against Hong Kong companies?

We have not seen public reports of Hong Kong victims. CISA's listing confirms exploitation in general, without naming targets.

Does this affect other Ruby applications?

According to Ruby, only applications that compile regular expressions from attacker-controlled input are affected. Updating Ruby is still sensible.