Skip to content

Response, New York. Noah Park: Check Point Patches Actively Exploited Management Server Path Traversal. Detection, Dallas. Ava Okello: Report Finds Nearly Half of Deployed Detections Need Attention Before SOCs Can Trust Them.

SOCtember

Always First. Fast SOC News.

Top of Alpine Linux's incident post, titled GitLab security incident: attempted exploitation of CVE-2026-97229, dated Oct. 28, 2026.
Image: Alpine Linux (fair use). The project's incident notice, published Oct. 28, 2026.

Response

Alpine Linux Says an Attacker Tried to Exploit CVE-2026-97229 on Its Own GitLab, and Upgrading GitLab Alone Did Not Close the Hole Because the Fix Lives in Ruby

The project's Oct. 28 notice says the CVSS 10.0 CI regex flaw crashed workers eight times and came close to working. Alpine rebuilt the server after finding no proof of code execution but also no way to rule it out, and warned anyone running GitLab on their own Ruby that the GitLab version string is not enough.

Noah Park, ResponseNew York6 min read

NEW YORK - The Alpine Linux project said Wednesday that an attacker tried to exploit a critical GitLab vulnerability on the project's own GitLab server a week after the fix was released, and that a routine upgrade it made in the middle of the incident did not close the hole, because the fix is a patch to Ruby rather than to GitLab's code.

"The attack came close to working," the project wrote. Alpine found no evidence that the attacker ran code on gitlab.alpinelinux.org but could not rule it out, so it treated the instance as compromised, rebuilt it from scratch, reset every password and replaced GitLab's secret keys. Its checks show that the aports repository, its packages and its Oct. 21 releases were not tampered with, and the keys that sign Alpine packages and releases have never been stored on the GitLab server.

A newly registered account and eight crashes

The flaw, CVE-2026-97229, is rated 10.0 on the CVSS scale. GitLab's Oct. 12 patch release says it could allow an unauthenticated user to execute arbitrary code on a GitLab server through a specially crafted regular expression in a CI/CD configuration, and lists affected GitLab CE and EE versions from 19.2 before 19.2.8, 19.3 before 19.3.5 and 19.4 before 19.4.2. The underlying bug is in Onigmo, the regular expression engine built into Ruby.

Incident timeline table from Alpine Linux's post, running from Oct. 12 to Oct. 28.
Image: Alpine Linux (fair use).Alpine's timeline, from GitLab's fix to the rebuilt server.

Alpine's timeline shows how the gap opened. On Oct. 13 it upgraded to GitLab 19.3.4 instead of 19.3.5, which had the fix, "by mistake." On Oct. 20 a newly registered account began probing, and on Oct. 20 and 21 it sent crafted CI configurations that crashed GitLab worker processes 8 times. In 4 of those crashes, Alpine says, the attacker got partway through the exploit and failed at the next step. The attacker also downloaded Alpine's GitLab container image, which the project said "suggests they were tuning the exploit to our exact build." The main attack on Oct. 21 caused GitLab crashes, 502 errors and failed CI jobs.

Alpine upgraded to GitLab 19.3.6 on Oct. 22 and blocked the account on Oct. 23. The attacker returned on Oct. 25 and 26 and failed to get back in. Only on Oct. 26 did the team find that the instance was still vulnerable.

Why the upgrade did not help

GitLab ships the fix as patches to the Ruby it bundles in its own packages and container images. Alpine's image used standard Ruby, so it never got them. Upstream Ruby shipped the underlying fixes on Oct. 23 in Ruby 4.0.9, 3.4.12 and 3.3.13, saying GitLab found that specially crafted patterns "could corrupt memory while Ruby compiles them, and that this could be turned into remote code execution on GitLab servers."

Ruby's Oct. 23, 2026 news post on Regexp compilation fixes related to four GitLab CVEs, including CVE-2026-97229.
Image: Ruby (fair use).The upstream Ruby releases that carry the Onigmo fixes.

"If you run GitLab with your own Ruby (from source or in your own container image) rather than GitLab's packages, upgrading GitLab is not enough," Alpine wrote. Those servers also need Ruby 3.3.13, 3.4.12, 4.0.9 or later. Users of Alpine's alpinelinux/gitlab image need to pull 19.3.6 again; the image published on Oct. 27 contains Ruby 3.3.13, and any 19.3.6 image pulled before that date is vulnerable. Because the bug is in Ruby's regular expression engine, Alpine added, "any program that compiles regular expressions from untrusted input is exposed, not only GitLab."

What responders should take from it

Alpine was candid about the limits of its evidence. "A successful exploit would leave no crash and no trace in the web logs," it wrote. Background job logs and the old container's filesystem from the attack day are gone, and neither Alpine nor its hosting provider logged outbound network connections.

Section of Alpine Linux's post listing what the project found, why it cannot be sure, and what could have been exposed.
Image: Alpine Linux (fair use).What Alpine could confirm, and what it could not.

If the attack had succeeded, Alpine says, exposed data could include users' email addresses, names and IP addresses, password hashes, 2FA secrets, CI/CD variables and runner tokens, webhook, integration and push mirror credentials, personal access tokens stored as hashes, and private repositories and confidential issues. The project is changing how it runs the server: applying critical GitLab security releases within a day and checking each for Ruby or other component patches, recording outbound connections from the GitLab host and database connections, keeping logs longer than 14 days, and signing release tags so releases can be verified without GitLab.

For teams running self-managed GitLab, the checks are concrete. Confirm which Ruby the GitLab processes actually load, not only the GitLab version string. Look for CI lint and pipeline requests that crash workers, which is what Alpine saw. GitLab's patch release lists six threat detections for CVE-2026-97229 exploitation attempts on self-managed instances, including "Onigmo native worker crash" and "ci lint workhorse worker crash." And if an instance was reachable while unpatched, plan for the secrets on it, not only the passwords, as Alpine did when it treated its server as compromised.

Sources:


Noah Park covers incident response and blue-team operations for SOCtember from New York.

Related stories

Response desk