The GitLab bug we flagged is now on CISA’s exploited list, and Alpine Linux’s upgrade did not fix it

By George Bailey   Published: 10/30/26   5 min read

We flagged this GitLab bug on October 13, and GitLab shipped a second 10.0 fix a week later. This week the first one got worse. CISA put CVE-2026-97229 on its exploited list on Thursday, and Alpine Linux explained how an attacker came close to running code on its GitLab server.

Get the CyberExperts Daily Brief: the day's top security news in 5 minutes. Free.

The detail that matters for your own server: Alpine upgraded GitLab and was still vulnerable. The fix lives in the Ruby that GitLab bundles, and a server on its own Ruby does not get it from a GitLab update.

Alpine upgraded GitLab and was still open. The fix is in the Ruby underneath, so check which Ruby your server actually runs.

CISA lists the GitLab bug we flagged, and Alpine Linux almost lost its server to it

CISA added CVE-2026-97229 to the Known Exploited Vulnerabilities catalog on October 29 with a due date of November 1, and it lists forensic triage as required. GitLab rates the integer overflow in its CI/CD regular expression handling 10.0. It fixed the flaw on October 12 in 19.4.2, 19.3.5 and 19.2.8.

On October 28 the Alpine Linux project published its incident report. A newly registered account sent crafted CI configurations to gitlab.alpinelinux.org on October 20 and 21, crashing GitLab worker processes eight times. In four of those crashes the attacker got partway through the exploit and failed at the next step. Alpine found no evidence that code ran, but it cannot rule it out, so it rebuilt the server from scratch, reset every password and replaced GitLab’s secret keys.

Alpine had installed 19.3.4 on October 13 instead of 19.3.5, which it calls a mistake. When it moved to 19.3.6 on October 22, the server stayed vulnerable, because its container image used a standard Ruby. Alpine says it found no tampering with its packages or the October 21 releases, and its signing keys were never on that server.

Self-built GitLab installs that run their own Ruby

GitLab’s fix is a set of patches to the Ruby that ships inside GitLab’s own Linux packages and container images. The bug is in Onigmo, the regular expression engine inside Ruby. Ruby published its own fixed versions on October 23: 3.3.13, 3.4.12 and 4.0.9. Ruby 3.2 gets no fix.

So the exposure depends on how you installed GitLab. Official packages and official images carry the patched Ruby once you upgrade. Source installs and homemade container images need the Ruby update as well. The Hacker News reports that as of October 29 neither GitLab patch post told administrators of self-compiled installs to update Ruby.

Rapid7 published working exploit code on October 13. Its route needs write access to a public project first, a step that disappears on servers where new users can register themselves and create projects. Alpine has not said how its attacker’s configurations reached the server.

Update GitLab, check Ruby, then look for signs of entry

Forward this

For whoever runs our GitLab: CISA says a 10.0 GitLab flaw is being exploited, and Alpine Linux nearly lost its server to it because upgrading GitLab did not fix their Ruby. Can we confirm how our GitLab is installed (official package, official image or our own build), what Ruby it runs, and whether strangers can register and create projects? If it is our own build, Ruby needs an update too.

Details

Hunt / verify

Source: CISA KEV addition, October 29; Alpine Linux incident report

Sources

George Bailey

George Bailey is the byline of the CyberExperts editorial desk, the team behind the CyberExperts Daily Brief. The desk covers vulnerabilities, breaches and security news from vendor advisories, CISA alerts and other primary sources, and links those sources in every story. Questions or corrections: [email protected].