GitLab shipped a critical patch on October 12 for a CVSS 10.0 bug in self-managed installations. If you run your own GitLab, go to 19.4.2, 19.3.5 or 19.2.8 now.
GitLab.com is already patched. Dedicated customers don’t need to do anything. This one is entirely a self-hosters’ problem.
The bug
CVE-2026-97229 is an integer overflow in the CI/CD regular expression compiler. Insufficient validation on a regex in a CI/CD config lets an attacker run arbitrary code on the server. The vector is remote, low complexity, no privileges, no user interaction, which is how you get to a clean 10.0.
Affected: everything from 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2, in both Community and Enterprise editions.
Note the version numbers, because a few writeups have the 19.3 fix as 19.3.4. It’s 19.3.5.
Worth being precise about “unauthenticated”
GitLab describes it as unauthenticated code execution. Rapid7, who reproduced it, found the practical path needs an attacker to commit a crafted .gitlab-ci.yml plus a repository path containing UTF-8 characters to a branch in a public project.
On a self-managed instance that lets ordinary users create public projects, an ordinary account clears that bar. So “unauthenticated” in the advisory and “any rando with a login” in practice land in roughly the same place, and if your instance allows public project creation you should treat it as the worse reading.
Rapid7 confirmed the input that worked against an unpatched 19.4.1 image failed against 19.4.2. No confirmed exploitation in the wild as of the advisory, and no public proof of concept at that point. That’s the quiet window, and the quiet window is exactly the part people spend badly. A patch with no exploit yet feels optional right up until somebody publishes the details, and then the decision gets made for you.
The self-hosting tax
We spend a lot of this site telling people to run their own things. This is the other side of that ledger and it deserves saying plainly.
When you self-host, you are the security team. Nobody pushes the patch for you, nobody notices your instance is three minor versions behind, and the vendor’s advisory is the only alert you get. GitLab did its part here: fix shipped, advisory published, severity stated accurately. Everything after that is on whoever runs the server.
Which is fine, and it’s the actual cost of owning your stack. The cost just isn’t the hardware or the setup weekend. It’s a standing obligation to read release notes for everything you run, forever, and to patch inside days rather than quarters when something lands at a 10.
If that obligation isn’t realistic for a given service, that’s a legitimate reason to use the hosted version instead. Running your own GitLab and ignoring it for a year is worse than not running your own GitLab.
While you’re in there
Upgrade self-managed instances now and prioritize anything internet-facing. If you find any sign of compromise, rotate the secrets and tokens stored in GitLab, because CI credentials are the whole prize on a build server.
And ask whether the instance needs a public address at all. Same question as always.
Sources: Help Net Security on CVE-2026-97229 and Rapid7’s reproduction.