GitLab CVE-2026-97229: Alpine attacked, Ruby must be updated too

ARX News has already covered CVE-2026-97229 in GitLab Community Edition (CE) and Enterprise Edition (EE), the CVSS 10 unauthenticated code execution flaw tied to regular expressions in CI/CD configurations, and its addition to CISA’s KEV catalog on 29 October. At that point no details about the attacks were known. Now there is a first documented case: the attempted exploitation of the GitLab instance run by Alpine Linux, the distribution used as the base of a great many container images.

The Hacker News, SecurityWeek and heise Security have reported on it. The details below come from Alpine Linux’s own statement, as reported by SecurityWeek.

What happened at Alpine Linux

According to Alpine Linux, the attack took place on 20 and 21 October, about a week after GitLab’s 12 October advisory:

• the attacker used a newly registered account to send crafted CI configurations to the instance, crashing the worker process;
• in 4 of those crashes the exploit got partway through and failed at the next step;
• the attacker also downloaded Alpine’s GitLab container image: according to the distribution, this suggests they were tuning the exploit to its exact build.

Alpine Linux says it found no evidence that code was run on the server, but cannot rule it out. It therefore rebuilt the instance from scratch and is still testing it before reopening it to the public. According to its checks, the aports repository, the packages and the 21 October releases were not tampered with.

It has also reset all passwords, warning of automated login attempts using passwords leaked in other breaches. The source does not say whether these come from the same attacker.

The technical point: the flaw is in Ruby

According to SecurityWeek, CVE-2026-97229 stems from insufficient regular expression validation in Onigmo, the regular expression engine of Ruby. heise Security also attributes the critical GitLab flaws to bugs in Ruby’s regex engine.

Alpine Linux experienced the practical consequence first-hand: its image runs GitLab on the distribution’s standard Ruby, not on the one shipped in GitLab’s packages. As a result, according to SecurityWeek, the vulnerability remained open even after upgrading to GitLab 19.3.6, one of the versions ARX News listed as safe.

Alpine Linux’s guidance is explicit: if you run GitLab with your own Ruby (installed from source or in a container image you build yourself), upgrading GitLab is not enough; you also need Ruby 3.3.13, 3.4.12, 4.0.9 or later.

A check based only on the GitLab version can therefore report as fixed an instance that is still vulnerable. The available sources do not say whether the same applies to CVE-2026-110264, fixed by GitLab on 21 October and also described as an integer overflow in the regular expression compiler.

Techniques and indicators

In MITRE ATT&CK terms, the pattern remains exploitation of a public-facing application (T1190), using an ordinary account created on the instance. This is consistent with the conditions described by Rapid7 in mid-October, which required the ability to create public projects. The login attempts with leaked passwords correspond to credential stuffing (T1110.004).

The sources report no indicators of compromise (IP addresses, account names, hashes). The only signals described are behavioural: new accounts, anomalous CI configurations and repeated worker crashes.

Impact for European and Italian organisations

The case confirms that CVE-2026-97229 is being used against real targets and that attackers spend time tailoring the exploit to individual installations. The most exposed are self-managed instances with open registration and those running on a Ruby not supplied by GitLab: custom container images, source installations, distribution packages.

For users of Alpine Linux images and packages, the distribution states that its repository, packages and 21 October releases are intact: based on the sources, no action is needed.

For organisations within the scope of NIS2, what we wrote before still applies: vulnerability management, software supply chain security and, in the event of a significant incident, notification to the national CSIRT (in Italy, CSIRT Italia at ACN).

What to do now

1. Check how GitLab is installed: GitLab’s official packages, or your own Ruby (source, home-built image, distribution packages).
2. If the Ruby is yours: check the version used by the GitLab processes and bring it to at least 3.3.13, 3.4.12 or 4.0.9, then restart the services so they load the new runtime.
3. Update GitLab anyway to at least 19.2.9, 19.3.6, 19.4.3 or 19.5.1, as already advised for CVE-2026-110264.
4. Review your vulnerability checks: if your scanner looks only at the GitLab version, add a check of the Ruby version.
5. Look for the signals described by Alpine Linux: recently registered accounts, anomalous CI configurations submitted by those accounts and repeated worker process crashes from 12 October onwards.
6. Logins: review failed login attempts and, where possible, enforce two-factor authentication; consider restricting open registration.
7. If you find suspicious activity: treat the server as exposed, as Alpine Linux did, verify the integrity of repositories and release artifacts, replace passwords and pipeline secrets, and assess your notification obligations.

How ARXDOME helps

ARX Expose shows which services your organisation exposes on the Internet, which products are recognised on them and which have known vulnerabilities: it helps you find out whether a GitLab instance is reachable from outside. ARX Shield lists the open vulnerabilities on monitored machines. ARX Sentry collects logs and events from servers where the agent is installed and checks file integrity in designated folders. With ARX Horizon you can look up vulnerability details from the portal.

Last updated: 30 October 2026