GitLab security incident: attempted exploitation of CVE-2026-97229

Key points

Alpine Linux reports that an attacker tried to exploit the GitLab vulnerability CVE-2026-97229 against gitlab.alpinelinux.org on October 20 and 21, a week after GitLab released a fix. The project found no evidence that the attack succeeded but cannot exclude it, so it treated the instance as compromised and rebuilt it from scratch. Its checks show the aports repository, packages and the October 21 releases were not altered.

What users need to do

• Every GitLab password has been reset. When the instance reopens, set a new one through "Forgot your password?" on the sign-in page. The project will publish exact steps at reopening.
• If your gitlab.alpinelinux.org password is also used on other sites, change it there. Automated login attempts using passwords leaked elsewhere have been seen.
• Package mirrors, cgit, mailing lists and IRC remain available while GitLab is closed.
• Questions go to [email protected].

The vulnerability

• CVE-2026-97229 is rated critical (CVSS 10.0). It affects how GitLab evaluates regular expressions in CI configuration, and the root bug is in Onigmo, the regex engine built into Ruby.
• GitLab's October 12 releases fix it by patching the Ruby bundled in GitLab's own packages and container images, not GitLab's code.
• Upstream Ruby released the fix on October 23 in 3.3.13, 3.4.12 and 4.0.9.
• If you run GitLab on your own Ruby (from source or a custom container image), upgrading GitLab alone is not enough. You also need Ruby 3.3.13, 3.4.12, 4.0.9 or later.
• Users of the alpinelinux/gitlab image should pull alpinelinux/gitlab:19.3.6 again. The build published October 27 includes Ruby 3.3.13. Any 19.3.6 image pulled before that date, and all older tags, are vulnerable.

Alpine's ruby package

• Any program that compiles regular expressions from untrusted input is exposed, not only GitLab.
• Alpine 3.22, 3.23, 3.24 and edge ship Ruby 3.4.12, and Alpine 3.21 ships Ruby 3.3.13. Both contain the fix, which an upgrade installs:

apk upgrade

Timeline

• Oct 12: GitLab publishes the fix.
• Oct 13: The CVE is published. Alpine upgrades to 19.3.4 by mistake instead of 19.3.5, which contained the fix.
• Oct 20: A newly registered account begins probing.
• Oct 21: In the main attack, crafted CI configurations crash GitLab workers 8 times, causing 502 errors and failed CI jobs. In 4 crashes the exploit got partway and then failed. The attacker also downloaded Alpine's GitLab container image, which suggests the exploit was being tuned to that build.
• Oct 22: Upgrade to GitLab 19.3.6. It did not close the hole because Alpine's image used standard Ruby without GitLab's patch.
• Oct 23: The attacker's account is blocked, and Ruby publishes its fix.
• Oct 24: aports, packages and the Oct 21 releases are checked against outside records.
• Oct 25–26: The attacker tries to get back in and fails.
• Oct 26: The instance is found to be still vulnerable.
• Oct 27: GitLab is closed to everyone except developers and build servers, and the rebuild begins.
• Oct 28: The rebuild is finished, all passwords are reset and GitLab's secret keys are replaced.

Packages and releases

• The Oct 21 stable releases 3.21.9, 3.22.7, 3.23.7 and 3.24.3 come from verified aports commits. This covers their ISO images and the minirootfs tarballs behind the official alpine Docker images.
• Every aports commit from Oct 20–22 came from a recorded push by a known developer. This was checked against a developer's clone and all 45 builders, which the attacker could not reach.
• All packages built Oct 20–24, on every architecture, match the commits published on git.alpinelinux.org.
• The checks so far cover commits through Oct 22 and builds through Oct 24. They are being extended to Oct 27, when GitLab was closed.
• The keys that sign packages and releases have never been stored on the GitLab server.

What is known and what is not

• Timing probes showed no delays, and no unexpected files, keys, hooks or processes were found.
• No private data was returned to the attacker in any web or API request the team can see.
• However, a successful exploit would leave no crash and no web log entry.
• Some logs from the attack day are lost, including background job logs and the old container's filesystem.
• Neither Alpine nor its hosting provider logged outbound network connections.

Data at risk if the exploit worked

• Email addresses, names and IP addresses of all users.
• Password hashes, 2FA secrets, CI/CD variables and runner tokens.
• Webhook, integration and push mirror credentials.
• Personal access tokens (stored hashed).
• Private repositories, confidential issues and confidential merge requests.

Planned changes

• The rebuilt instance runs a fixed Ruby (3.3.13 or later).
• Critical GitLab security releases will be applied within a day, and each release will be checked for Ruby or other component patches the self-built image must include.
• Outbound connections from the GitLab host and database connections will be logged, with retention longer than 14 days.
• Release tags will be signed so releases can be verified independently of GitLab.

Summary by DistroNews, based on the original post.