Attackers Are Using a Max-Severity GitLab Flaw: A Checklist for Engineering Firms That Host Their Own Code

A maximum-severity GitLab flaw is now being used in real attacks. On Oct. 29, 2026, CISA added CVE-2026-97229 to its Known Exploited Vulnerabilities list and gave federal agencies until Nov. 1 to fix it. GitLab says the bug "could have allowed an unauthenticated user to execute arbitrary code on the GitLab server via a specially crafted regular expression in a CI/CD configuration." It only affects GitLab you run yourself: GitLab says GitLab.com and GitLab Dedicated are already patched.

That makes this a question for engineering firms, manufacturers, agencies and any business with an in-house developer or contractor who set up a GitLab server for code, CAD scripts, machine programs or website builds. Those servers are easy to forget, and they usually hold passwords and keys to everything else.

What's been reported

GitLab fixed it on Oct. 12. GitLab's Oct. 12 patch release (19.4.2, 19.3.5 and 19.2.8) fixed CVE-2026-97229, rated CVSS 10.0, and GitLab "strongly" recommended that all self-managed installations upgrade "immediately." It also published six detections to help spot exploitation attempts.
A related fix followed on Oct. 21. GitLab's Oct. 21 critical patch release (19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13) fixed a second CVSS 10.0 regular-expression bug, CVE-2026-110264, that it says affects versions as far back as 7.0. So "we patched on the 12th" isn't enough.
The attack CISA's listing follows. Alpine Linux says a newly registered account sent crafted CI configurations to its GitLab server on Oct. 20 and 21, crashing it 8 times; in 4 of those crashes the attacker "got partway through the exploit and failed at the next step." Alpine found no evidence the attack succeeded but says "we cannot rule it out," so it rebuilt the server from scratch. It says its software releases and packages weren't tampered with.
Upgrading GitLab alone didn't fix Alpine's server. The fix is a patch to Ruby that GitLab bundles in its official packages. Alpine ran GitLab on its own Ruby, so its Oct. 22 upgrade left the hole open. Alpine says anyone running GitLab from source or a home-built container also needs Ruby 3.3.13, 3.4.12, 4.0.9 or later, which Ruby released on Oct. 23.
The cleanup was big. When Alpine reopened its GitLab, it had reset every password and two-factor setup, cancelled all access tokens and wiped stored CI/CD variable values, and told users to "assume the old values may have been exposed." It also reported automated login attempts using passwords leaked from other sites.
How many servers are exposed? BleepingComputer reports that Shadowserver tracks nearly 2,800 internet-exposed GitLab Community Edition instances. That's exposure, not confirmed break-ins.

Why it matters for engineering firms and shops

A self-hosted GitLab often holds more than code. Its CI/CD settings tend to store cloud keys, database passwords, deployment credentials and service accounts, and its build runners may sit inside the office network. If someone runs code on that server, those secrets are the prize. Small firms also tend to leave sign-up open, keep a server running long after the developer who built it has moved on, and skip updates because "it's just the code server."

The Alpine case is the cautionary tale. Its team upgraded the day after the CVE was published but picked a release one step short of the fix by mistake, then upgraded again on Oct. 22 and found on Oct. 26 that the server was still exposed because of how it was built. Version numbers need checking, not assuming.

Clear takeaway

If anyone runs a GitLab server for your business, confirm this week that it's on GitLab's latest patch release for its version line (at least the Oct. 21 releases), that it uses GitLab's own packages or a patched Ruby, and that open sign-up is off; if it's on GitLab.com, you don't need to patch anything.

What to do this week

Find every GitLab. Ask your developers, contractors and IT provider whether any GitLab server exists for your business, in the office, in the cloud or on an old virtual machine. If you only use GitLab.com, note that and move on to step 6.
Get the version and how it was installed. Ask for the exact GitLab version and whether it runs from GitLab's official package or container, or from source or a custom image.
Patch to the newest release. Upgrade to the latest patch release for that version line, at least 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13. If it's built on its own Ruby, also confirm Ruby 3.3.13, 3.4.12, 4.0.9 or later, in writing.
Shrink who can reach it. Turn off open sign-up so strangers can't create accounts, and if the server doesn't need to be on the internet, put it behind the VPN.
Look for the warning signs. Ask whoever runs it to check for unknown new accounts, odd CI pipelines and repeated worker crashes since mid-October, using GitLab's published detections.
Rotate secrets if in doubt. If the server was unpatched and reachable after Oct. 12, treat its stored CI/CD variables, access tokens and deploy keys as exposed: replace them, and change any reused passwords. Turn on two-factor sign-in for every account.
Keep a clean rebuild option. Make sure there's a recent backup of the repositories and settings stored somewhere the GitLab server can't change, so a rebuild like Alpine's takes days, not weeks.

How Brotherly Technology can help

Brotherly Technology can track down forgotten code servers, confirm GitLab and Ruby versions, apply the updates, lock down sign-up and remote access, and rotate the passwords and keys your builds depend on. If you're not sure whether your developer set up a GitLab server, call us and we'll find out.