Sadeem IT Solutions
30 Oct 2026

GitLab flaw under active attack: why the update alone is often not enough (CVE-2026-97229)

A GitLab vulnerability rated CVSS 10 is being actively attacked, and US agency CISA has listed it as exploited since 29 October. If you run GitLab with your own Ruby, you also need to update Ruby.

gitlab-ci-luecke-aktiv-angegriffen-cve-2026-97229

On 12 October 2026, GitLab fixed a critical vulnerability: CVE-2026-97229, rated with the maximum score of CVSS 10.0. The warning has since become reality. Attackers tried to take over the GitLab server of the Alpine Linux project with it, and the US cybersecurity agency CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalogue on 29 October.

The case also reveals a trap that many overlook: updating GitLab alone does not protect you in every setup. The bug is not in GitLab itself but in Ruby, the programming language GitLab is built on.

What happened

GitLab evaluates regular expressions (regex) in CI/CD pipelines, i.e. search patterns in the .gitlab-ci.yml configuration file. The regex engine responsible is called Onigmo and is part of Ruby. A crafted pattern causes a numeric value to overflow (integer overflow), memory gets corrupted, and an attacker can run their own code on the GitLab server without logging in.

Timeline:

  • 12 October: GitLab releases 19.4.2, 19.3.5 and 19.2.8 with the fix.
  • 13 October: Security firm Rapid7 reproduces the attack; a public proof of concept follows shortly afterwards.
  • 20 to 26 October: An attacker registers an account on Alpine Linux's GitLab server and repeatedly crashes processes with crafted CI configurations. According to Alpine, the attacker got partway through the exploit. Alpine had first installed a version without the fix by mistake, and later found that its own container image used a separately installed Ruby that remained vulnerable.
  • 21 October: GitLab fixes a second CVSS 10 flaw (CVE-2026-110264) in 19.5.1, 19.4.3, 19.3.6 and 19.2.9.
  • 23 October: The Ruby project releases Ruby 4.0.9, 3.4.12 and 3.3.13 with the fixes.
  • 27 and 28 October: Alpine rebuilds its GitLab server from scratch and replaces all passwords and keys. According to the project, no tampered packages were found.
  • 29 October: CISA classifies the flaw as actively exploited. US federal agencies must act by 1 November.

Who is affected

Self-managed GitLab servers (Community and Enterprise Edition) running versions 19.2 to 19.4 before the fixes above are affected. GitLab.com and GitLab Dedicated are already patched.

Instances where new users can register themselves or create public projects are at particular risk. According to Rapid7, an ordinary account is then enough for the attack.

In addition:

  • If you run GitLab from the official Linux packages or container images, the GitLab update brings the fixed Ruby with it.
  • If you install GitLab from source or use your own image with a separate Ruby, you must update Ruby as well.
  • Other Ruby applications can be affected too if they build search patterns from user input. According to the Ruby project, a regex timeout does not protect against this.

What you should do now

  1. Check your version: in the GitLab admin area or via cat /opt/gitlab/embedded/service/gitlab-rails/VERSION on the server.
  2. Move to a current version: at least 19.4.3, 19.3.6 or 19.2.9, preferably the latest release of your branch or 19.5.x. These also close the second critical flaw, CVE-2026-110264.
  3. Check Ruby if you compile GitLab yourself or build your own image: at least Ruby 3.3.13, 3.4.12 or 4.0.9. Ruby 3.2 is no longer maintained and should be replaced.
  4. Pull container images again: a tag with the same name can still point to an outdated image. Alpine explicitly notes that images pulled before 27 October were affected.
  5. Reduce the attack surface: disable self-registration or require admin approval, and restrict public projects and anonymous access. This does not replace the update, but it makes the known attack path much harder.
  6. Look for traces: unusual crashes of GitLab processes, failed CI jobs with odd configurations, and new, unknown accounts since 12 October are warning signs. If in doubt, treat the server as compromised, rebuild it and rotate all tokens, runner registrations and credentials.
  7. Keep logs longer: Alpine could not rule out a successful attack with certainty, because logs were kept only briefly and outbound connections were not recorded.

How Sadeem helps

We operate GitLab, containers and Linux servers for small and mid-sized companies on infrastructure in Germany and the EU. This includes prompt security updates, checks of bundled components such as Ruby, monitoring and backups. On request, we can review your GitLab instance at short notice, install the updates and configure registration and project visibility securely. If you are unsure whether your server is affected, feel free to book a free initial consultation.

Sources

SecurityGitLabCVE