Skip to content
audiotale.net
Sign in
NewsNews

CVE-2026-97229: GitLab flaw hit Alpine's server, and patching GitLab alone was not enough

Alpine Linux says an attacker nearly exploited the CVSS 10.0 GitLab bug on its own server; the root cause is in Ruby, so self-built installs also need Ruby 3.3.13, 3.4.12 or 4.0.9.

audiotale.net team

· 8 min read

Written by AI from the sources linked below. How we use AI

On this page
  1. Key points
  2. What to do
  3. What happened
  4. Background
  5. How it works
  6. What it means
  7. What we don't know yet
  8. What to watch next
  9. Sources

An attacker tried to exploit CVE-2026-97229, the CVSS 10.0 GitLab flaw patched on 12 October 2026, against Alpine Linux's own GitLab server on 20 and 21 October, and came close enough that the project rebuilt the whole instance. Alpine's incident report, published on 28 October, found no evidence that the attacker ran code but says it cannot rule it out. The report also carries a warning for everyone who runs GitLab outside GitLab's own packages: upgrading GitLab alone may not close the hole, because the real bug sits in Ruby's regular expression engine.

Key points

  • CVE-2026-97229 is an integer overflow in GitLab's CI/CD regular expression compiler, rated CVSS 10.0, fixed in GitLab 19.4.2, 19.3.5 and 19.2.8 on 12 October 2026.
  • Alpine Linux says an attacker probed its GitLab on 20 October and made the main attempt on 21 October, causing 8 worker crashes; it found no proof of code execution but rebuilt the server and reset passwords and secret keys.
  • The underlying flaw is in Onigmo, Ruby's regex engine. Upstream Ruby shipped the fix on 23 October in Ruby 3.3.13, 3.4.12 and 4.0.9.
  • GitLab's own packages and images bundle a patched Ruby; self-built installs and images that use a stock Ruby need the fixed Ruby as well as the fixed GitLab.
  • GitLab's release notes did not report exploitation in the wild at disclosure; Alpine's report describes an attempted attack on its own server.

What to do

  • Who is affected: self-managed GitLab CE and EE from 19.2 before 19.2.8, from 19.3 before 19.3.5, and from 19.4 before 19.4.2. GitLab.com is already patched, and GitLab Dedicated customers need take no action, according to GitLab.
  • Fix: upgrade to 19.4.2, 19.3.5, 19.2.8 or later. GitLab says the patch includes database migrations, so single-node instances will have downtime; multi-node instances can use the zero-downtime procedure. Instructions are on GitLab's update page.
  • Check your Ruby: if you build GitLab from source or in your own container image, also run Ruby 3.3.13, 3.4.12, 4.0.9 or later. Alpine's report puts it bluntly: "upgrading GitLab is not enough".
  • Alpine's image: any alpinelinux/gitlab 19.3.6 image pulled before 27 October, and all older tags, are vulnerable. Pull alpinelinux/gitlab:19.3.6 again. On Alpine hosts run apk upgrade to get the fixed ruby package (3.3.13 on Alpine 3.21; 3.4.12 on 3.22, 3.23, 3.24 and edge).
  • If you cannot patch today: Rapid7 suggests temporarily restricting credential-free access to public projects that outsiders can write to, or blocking the CI lint route. It stresses that blocking the route does not fix the compiler.
  • How to look for an attempt: Rapid7 lists Workhorse log entries showing a long CI lint GET followed by a 502 and a Puma worker crash, and commits with unusual split repeat quantifiers or four-byte UTF-8 paths. GitLab says it released six threat detections for self-managed instances.

What happened

GitLab shipped a critical patch release on 12 October 2026 that fixed 24 vulnerabilities, one of them CVE-2026-97229. GitLab describes it as an integer overflow in the CI/CD regular expression compiler: under certain conditions an unauthenticated user could run arbitrary code on the GitLab server by using a specially crafted regular expression in CI/CD configuration. The researcher, who goes by joaxcar, reported it through HackerOne. The CVE was published the next day.

Alpine Linux, which hosts its package sources and build infrastructure on its own GitLab, did not get the fix. Its report says it upgraded to GitLab 19.3.4 on 13 October by mistake, instead of 19.3.5, which carried the patch. On 20 October an attacker registered an account and began probing. On 21 October came the main attempt: eight worker crashes, 502 errors and failed CI jobs, four of which, Alpine says, got partway through the exploit. The attacker also downloaded Alpine's GitLab container image, which Alpine reads as a sign they were tuning the exploit to that exact build.

Alpine blocked the account on 23 October. It upgraded to GitLab 19.3.6 on 22 October believing that closed the issue, but the instance stayed vulnerable because its image used a stock Ruby without the patch. The attacker returned on 25 and 26 October and failed. On 26 October Alpine found the server was still vulnerable, on 27 October it closed GitLab to everyone except developers and build servers and began a rebuild, and on 28 October the rebuild was done, with passwords reset and GitLab's secret keys replaced.

Alpine is careful about what it does and does not know. It reports "no evidence that the attacker ran code on the server", but notes that a successful exploit would leave no crash or web-log trace, that some logs from the attack day are gone, and that it did not log outbound connections. Timing probes showed no delays, and it found no unexpected files, keys, hooks or processes. It checked the 21 October stable releases (3.21.9, 3.22.7, 3.23.7 and 3.24.3) and all packages built from 20 to 24 October against commits on git.alpinelinux.org and records held outside GitLab, and says they were not modified. Signing keys were never stored on the GitLab server, so none were exposed.

Background

The bug is not in GitLab's own code in the way the CVE title suggests. Ruby's note on the fixes, published on 23 October, lists four Onigmo bugs that GitLab reported and that Ruby fixed together: CVE-2026-89078 (a double free when pattern parsing fails after an alternation), CVE-2026-93577 and CVE-2026-97229 (the same integer overflow in the size of a compiled pattern) and CVE-2026-110264 (an overflow of internal IDs in a pattern with many repeats). Ruby says specially crafted patterns can corrupt memory during compilation, and that GitLab reported this could lead to remote code execution.

Rapid7's technical write-up, published on 16 October, explains how the overflow was reached. GitLab's check on the size of repeat bounds misses a quantifier split by an inline comment, so a bound above 1,000 gets through. The expanded program then overflows a signed 32-bit size check, and a miscalculated jump sends execution into attacker-controlled bytes. Rapid7 reproduced command execution as the git user on the official gitlab/gitlab-ce:19.4.1-ce.0 image on Linux amd64 with ASLR enabled. It says its proof of concept uses offsets specific to that build and needs roughly 2 GiB of extra memory in the worker.

GitLab's fix for its own customers was not a change to GitLab's source alone. Alpine's report says the fix "is a set of patches to the Ruby that GitLab bundles in its own packages and container images". That is why GitLab's official packages were protected from 12 October while upstream Ruby only shipped the fix on 23 October, eleven days later.

How it works

The attack, as Rapid7 describes it, abuses the way a regular expression is validated and then compiled again. A pattern that is valid as a compact US-ASCII expression passes GitLab's checks. Ruby's Onigmo engine then recompiles it for UTF-8, once the path it is matched against contains multi-byte characters, and the recompiled program is larger than the check allowed for. The overflow produces invalid instructions inside the engine, and that is what leads to running an operating system command.

Ruby's own note makes a point that matters beyond GitLab. The bugs matter to any application that compiles regular expressions from attacker-controlled strings, whether through Regexp.new, Regexp.union, Regexp.compile or interpolation into a literal. Ruby says Regexp.timeout does not protect against these bugs, and that limiting pattern length is unreliable because some of them trigger with short patterns. If you cannot upgrade, the advice is to avoid compiling regular expressions from untrusted input.

What it means

For self-hosters, the lesson is about the dependency under the dependency. A team that applied GitLab 19.3.6 on 22 October, as Alpine did, had every reason to think it was safe, and was not. Alpine's report says GitLab's own packages and container images bundle the patched Ruby, so installs from those get it along with the GitLab upgrade. Anyone who builds from source, or builds an image on a generic Ruby base, has to track Ruby releases as closely as GitLab releases.

For attackers, a public Ruby fix and a public technical analysis shorten the work: both Rapid7's analysis and Ruby's fix list are open, and Alpine saw an attacker downloading its container image to tune the exploit. This is an inference from one incident, and we do not know whether other instances were targeted.

For CI/CD security more broadly, Alpine's list of changes is a useful checklist: apply critical GitLab security releases within one day and check each for Ruby or other component patches, log outbound connections from the GitLab host and database connections, keep logs longer than 14 days, and introduce signed release tags so releases can be verified independently of GitLab.

What we don't know yet

  • Whether the attacker got code execution on Alpine's server. Alpine says it found no evidence, cannot rule it out, and lacks some logs.
  • Whether other instances were hit. No other victim has been named in the sources we read.
  • How unauthenticated the bug really is. GitLab rates it with no privileges required (PR:N). Rapid7 says its demonstrated setup needs a malicious CI configuration and a specially named path pushed to a public project, which conflicts with that rating, and that because the HackerOne report is private it does not know how the reported attack avoids that step. Only the final CI lint request needs no authentication.
  • Other affected Ruby applications. Ruby says the bugs matter wherever regexes are built from untrusted input; we have seen no list of such software.
  • CVE numbers for Ruby. Ruby's note says it has not requested CVEs for these fixes and recommends tracking them under GitLab's IDs.

What to watch next

Watch for GitLab or Ruby adding detail on the other three Onigmo CVEs, for downstream distributions and container images (Debian, Ubuntu, Docker Hub images, Helm charts) confirming that they ship a fixed Ruby, and for any listing of CVE-2026-97229 in CISA's Known Exploited Vulnerabilities catalogue. Alpine has said it will post instructions for resetting passwords when GitLab reopens.

Sources

SaveStart the discussion

Written by

audiotale.net team

The official account of the people who run audiotale.net: announcements, conversation starters and the newsroom's drafts. Posts written with AI say so. Every other account here is a real person.

Read next