Go Back Up

University of Sydney Code Library Breach: Disclosed 18 Dec, 2025

Personal details of about 27,500 current and former staff exposed.

18 Dec 2025 - Syd Uni breached
Read more

Check Your Ruby: GitLab CVE-2026-97229 Is Now Exploited

Blog Defence Emerging Threats 31 October 2026 6 min read

Cartoon of a cheerful technician holding a ticked clipboard beside a server rack labelled upgraded, while a cracked red ruby glows inside the rack and a raccoon in a hoodie sips coffee nearby

Most teams treat a vendor patch as the end of the story: the release notes say fixed, the upgrade job goes green and the ticket closes. The Alpine Linux project did exactly that with its GitLab server in October, and an attacker still spent two days working an exploit against it. The reason is a lesson for anyone running their own GitLab: the fix for CVE-2026-97229 (its Common Vulnerabilities and Exposures, or CVE, identifier) lives in Ruby, not in GitLab's own code.

On 29 October 2026 the US Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities (KEV) catalog, so this is no longer a theoretical 10.0 on the Common Vulnerability Scoring System (CVSS). In this post we'll cover what the bug is, why "we upgraded" may not mean "we're fixed", and what to check this week.

Key takeaways

  • CVE-2026-97229 is a CVSS 10.0 code execution flaw in self-managed GitLab Community Edition (CE) and Enterprise Edition (EE), and CISA now lists it as exploited.
  • If you run GitLab with your own Ruby (from source or in a home-built container image), upgrading GitLab alone does not fix it. You also need Ruby 3.3.13, 3.4.12, 4.0.9 or later.
  • Instances that let anyone register and create projects are the easiest targets.

What the bug actually is

GitLab lets users put regular expressions in continuous integration and continuous delivery (CI/CD) configuration, and it compiles them on the server. GitLab's critical patch release on 12 October 2026 describes an integer overflow in that regular expression compiler which, under certain conditions, lets an unauthenticated attacker run code on the server. The fixed releases are 19.4.2, 19.3.5 and 19.2.8. GitLab.com and GitLab Dedicated were already patched.

Rapid7 reproduced the full chain against an official unpatched image and ran commands as GitLab's git user. Their testing found the attacker first needs to commit a crafted CI file to a public project, and only the final step is unauthenticated. That sounds reassuring until you remember how many self-managed instances leave sign-up open. On those servers, any stranger can create the account and the project they need.

The underlying bug sits in Onigmo, the regular expression engine built into Ruby. GitLab fixed it by patching the Ruby it bundles in its Linux packages and official container images. Upstream Ruby shipped the fix on 23 October 2026, eleven days later.

Upgraded, but not fixed

That gap is where Alpine Linux's incident report gets interesting, and it deserves credit for being unusually frank. Alpine first upgraded to 19.3.4 rather than 19.3.5, which it calls a mistake. On 20 and 21 October a newly registered account sent crafted CI configurations to the server, crashing GitLab worker processes eight times. In four of those crashes the attacker got partway through the exploit. They also downloaded Alpine's GitLab container image, which Alpine reads as tuning the exploit to its exact build.

Alpine then upgraded to GitLab 19.3.6 on 22 October. It didn't help, because Alpine's image used standard Ruby and never received GitLab's patch. Alpine found no evidence that the attacker's code ran, but noted that a successful exploit would leave no crash and no trace in the web logs. It treated the server as compromised, rebuilt it from scratch and reset every password.

Cartoon of a relaxed sysadmin admiring a 'GitLab upgraded' message while a cracked, worried ruby gemstone sits unnoticed beside the server
The GitLab upgrade looks done, but the Ruby underneath is still broken.

We see the same pattern on penetration tests across many technologies. The version banner says patched, while the component that actually carries the bug was built from somewhere else. A vulnerability scanner that keys off the GitLab version will happily mark that server green.

What to do this week

Start by working out how each GitLab instance was installed, because that decides what "fixed" means:

  • Linux package or official GitLab container image: upgrade to the newest release on your branch. The 21 October releases (19.5.1, 19.4.3, 19.3.6 and 19.2.9) also fix a separate regular expression flaw, CVE-2026-110264.
  • Source installs or home-built container images: upgrade GitLab and confirm the Ruby on the server is 3.3.13, 3.4.12, 4.0.9 or later. Ruby 3.2 will not receive the fix, so move off it.
  • Third-party images: check which Ruby the image ships, and re-pull if the maintainer has rebuilt it. Alpine's own image was only fixed on 27 October.

Then reduce the exposure while you confirm the fix:

  • Turn off open sign-up, or require admin approval for new accounts.
  • Keep internet-facing GitLab behind a virtual private network (VPN) or an allow list where the business can tolerate it.
  • Review accounts created since 12 October, especially any that created public projects.

Finally, hunt rather than assume. GitLab has published six detections for exploitation attempts in its advisory. In plain English, the signals worth looking for are:

  • Unexplained crashes of GitLab application or Workhorse worker processes.
  • Bursts of CI lint requests, particularly from new or scripted clients.
  • CI configurations containing unusually large regular expressions, or repository paths with long runs of non-ASCII (American Standard Code for Information Interchange) characters.
  • New accounts that create a public project and immediately start validating CI files.

If any of those turn up on an unpatched server, follow Alpine's lead: treat it as compromised, rebuild, and rotate passwords, tokens, runner registration secrets and any CI/CD variables the server holds. Your build server holds the keys to everything it deploys, so it deserves the same care as a domain controller.

Conclusion

CVE-2026-97229 is a good reminder that a fix only counts if it reached the component with the bug. For most GitLab customers on official packages, the upgrade is enough. For anyone who builds their own, the question to ask today is "which Ruby are we running?"

If you'd like a second set of eyes on your source code and CI/CD platforms, or want to know whether an attacker could reach yours, talk to our penetration testing team. Think you've already been breached? Our incident response team can help.

Last updated: 1 November 2026

References

Ready to Transform your Business with Little Effort Using Brightlane?

Register Now