GitLab flaw now exploited: what to check

If your business runs its own GitLab server, check its version today. The US Cybersecurity and Infrastructure Security Agency (CISA) says a GitLab flaw rated 10 out of 10 is now being used in real attacks.

If you did the update from my GitLab post on 22 October, you're covered for this flaw, but read the bit about logs. An update doesn't tell you what happened before you installed it. If you only use GitLab.com, you can stop here.

What happened

On 29 October CISA added CVE-2026-97229 to its list of known exploited flaws, based on "evidence of active exploitation". This isn't the flaw I wrote about last time. It's an earlier one, which GitLab fixed on 12 October.

The bug is in how GitLab handles search patterns in a CI/CD configuration, the file that tells it how to build and test your code. A crafted pattern can let an attacker run their own code on your server.

CISA's entry doesn't say who is behind the attacks, and I'm not going to guess. But it gave US federal agencies only until today to deal with it, and asks for forensic triage as well as a patch. The Brotli flaw got two weeks.

Does it affect you?

GitLab rates this as needing no login at all. Rapid7, the security firm, looked at it closely and found the attacker first has to get a malicious CI file into a public project. On a server where a stranger can sign up and create a project, Rapid7 says that constraint "is removed". It has also reproduced the attack on an unpatched GitLab 19.4.1 and linked to a proof of concept, so the details are out there.

You use GitLab.com or GitLab Dedicated. Nothing to do.

You run GitLab yourself. This is the group to worry about, especially if it's on the internet with sign-ups open.

A developer or agency set it up for you. Ask them today which version it's on and who updates it.

What to do this week

1. Check your version. Signed in as an admin, the Help page shows it.

2. Update to the newest fix for your branch. GitLab's latest patch release came out on 29 October: 19.5.3, 19.4.5, 19.3.7, 19.2.10, 19.1.10, 19.0.11 or 18.11.14. The flaw on CISA's list was fixed earlier, in 19.4.2, 19.3.5 and 19.2.8, but the latest versions also carry the fix from my last post, plus a change that stops trusting some compromised security certificates.

Take a backup first and allow for a short outage, as I set out last time. GitLab says single-server installs will be down while the database changes run. Upgrading GitLab doesn't update GitLab Runner, so do that separately.

3. Close sign-ups if you don't need them. Go to Admin, Settings, General, then New user account restrictions, and clear "Allow new user accounts". GitLab's guide also shows how to require admin approval. Rapid7 says limiting who can create or write to public projects only closes the delivery route it demonstrated, so this doesn't replace the update.

4. Look at your users and projects. Go through the admin lists for accounts and public projects nobody recognises.

5. Check your logs. GitLab has published detection rules for this flaw. On a standard Linux package install, these two searches cover the simplest of them. The first looks for crash reports:

sudo grep -r "\[BUG\]" /var/log/gitlab/puma/

The second looks for failed requests to the pages an attack is likely to use:

sudo grep -rE '"uri":"[^"]*(ci/lint|/api/graphql)' /var/log/gitlab/gitlab-workhorse/ | grep -E '"status":502|badgateway'

A hit isn't proof, as a restart or an upgrade can cause the second one. GitLab calls that one a lead to investigate. A clean result isn't proof either, because GitLab says a successful attack can be quiet and leave nothing in these logs. Older logs may also have been compressed or rotated away.

If you find something

Don't just update and carry on. Keep a copy of the logs as they are, and treat the server as compromised. As I said last time, GitLab usually holds the keys to everything else, so change every password, token and SSH key stored in it, including your CI/CD variables. Then get it looked at properly.

If you have Ruby apps of your own

The underlying bug was in Ruby, the language GitLab is written in. The Ruby project says the fixes are in 4.0.9, 3.4.12 and 3.3.13, and only apps that compile patterns from untrusted input are at risk. If your app is built on Ruby, ask whoever looks after the code. If that's nobody any more, the team at Dev Partners can take a look through it.

The bigger point

The fix came out on 12 October, and by the end of the month the flaw was on CISA's list. If nobody in your business is going to keep an eye on the server in the corner, that's what a support retainer is for. I keep your servers updated, take the backups before I touch anything, and tell you about it in plain English.