KIungefiltert

· 4 min read · Auf Deutsch lesen

GitLab: Unauthenticated CVSS 10 Flaw Exploited, and One Patch Isn't Enough

CISA lists GitLab flaw CVE-2026-97229 (CVSS 10.0) as actively exploited. Alpine Linux was targeted, and a second regex bug makes the first October patch insufficient. What self-hosters should do now.

securityself-hosting

Translated from the German original with an AI language model, approved by me. Read the original

On October 29, 2026, the US cybersecurity agency CISA added the GitLab vulnerability CVE-2026-97229 to its Known Exploited Vulnerabilities (KEV) catalog. That list only includes flaws with evidence of real-world attacks. The bug scores CVSS 10.0, the top of the scale used to rate how severe a vulnerability is. I already flagged this on X and in the WhatsApp channel. Since then, something important has come up: if you patched only once in October, you may still be exposed.

What happened

According to GitLab's advisory, the bug sits in the compiler for regular expressions (regex, i.e. text search patterns) that GitLab uses for CI/CD configurations. CI/CD refers to the automated build and deploy pipelines. A crafted regex triggers an integer overflow, a calculation whose result is too large for the space reserved for it, so it "wraps around." The end result is that an attacker can run code on the GitLab server without logging in. Rapid7 traces the root cause to Onigmo, Ruby's regex engine.

It affects self-hosted GitLab Community Edition and Enterprise Edition. GitLab says GitLab.com and GitLab Dedicated are already patched. The fix shipped on October 12 in versions 19.2.8, 19.3.5 and 19.4.2. The next day, Rapid7 published a proof of concept, meaning code that demonstrates the flaw can be exploited.

The Alpine Linux case

As The Hacker News and heise report, an unknown attacker tried to exploit the flaw on Alpine Linux's GitLab server on October 20 and 21. Using a newly registered account, they sent crafted CI configurations. GitLab worker processes crashed eight times, and in four of those crashes the attacker got partway into the exploit. Later attempts on October 25 and 26 were blocked.

It's important to keep the attempt separate from any success. Alpine found no evidence that code ran, but it can't rule that out either. A successful exploit would leave no crash and no trace in the web logs, and some logs from the attack day are missing. So Alpine treated the server as compromised, rebuilt it, reset every password and rotated GitLab's secret keys. Package builds from October 20 to 24 matched records kept outside GitLab, and the signing keys were never on the server.

The most instructive part: on October 13, Alpine mistakenly upgraded to 19.3.4 instead of 19.3.5. Even the later upgrade to 19.3.6 didn't close the hole. That's because GitLab's fix lives in the Ruby that GitLab bundles with its own Linux packages and official images. Alpine's image used a standard Ruby instead. The fixed Ruby versions are 3.3.13, 3.4.12 and 4.0.9.

What has changed since the post

On October 21, GitLab fixed another flaw, CVE-2026-110264, also rated CVSS 10.0. It's also an integer overflow in the regex compiler and also allows code execution without logging in. GitLab says every version from 7.0 onward is affected. The fix is in 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. Several outlets, including eSecurity Planet, point out that the October 12 patches don't cover this second flaw. I found no reports of active exploitation for CVE-2026-110264, and only CVE-2026-97229 is on the KEV list.

For a sense of urgency: CISA recommends that US federal agencies apply the fixes by November 1, 2026. Formally that deadline only applies to those agencies, but it's a good benchmark for everyone else.

What you should do now

  • Update to the latest release, not just the first fix. That means at least 19.5.1, 19.4.3, 19.3.6 or 19.2.9, depending on your version branch. Those cover both regex flaws.
  • Check your Ruby if you don't run GitLab from the official packages or images, for example a source install or a distribution image. Ruby needs to be 3.3.13, 3.4.12, 4.0.9 or newer. If you use the alpinelinux/gitlab image, pull 19.3.6 again. Only the October 27 build includes the fixed Ruby.
  • Look for traces. Watch for clusters of worker crashes, 502 errors and failed CI jobs since October 12, and for newly registered accounts with odd CI configurations. GitLab provides detection rules for self-hosted instances, including "Onigmo native worker crash."
  • If in doubt, do what Alpine did. If you can't rule out a successful attack, rotate passwords, personal access tokens, runner tokens, CI/CD variables and webhook credentials.
  • Rethink open sign-ups. At Alpine, a freshly created account was all it took. If you don't need public registration, turn it off.

My take: the danger here isn't just the bug itself. It's the false sense of security after patching. Whether you're actually protected doesn't depend on the GitLab version number alone. It also depends on which Ruby is really running underneath.

Sources