GitLab Critical Patch: An Attacker With No Account Can Run Code on Your Server

If your company runs GitLab on its own server, update it today. On October 12, 2026, GitLab released a critical security patch that fixes 24 vulnerabilities. The worst, CVE-2026-97229, received the highest possible severity score: 10 out of 10. It lets someone with no account on your server run their own code on it. Every server running versions 19.2 before 19.2.8, 19.3 before 19.3.5, or 19.4 before 19.4.2 is affected. The only fix GitLab names is upgrading to 19.4.2, 19.3.5 or 19.2.8. If you use the cloud service at GitLab.com, you do not need to do anything.

What is GitLab, and why should a business owner care?

GitLab is where your technical team keeps the source code of your systems and apps, and where new versions are built and shipped to your servers. Many companies run it on an in-house server instead of the cloud service, to keep code and data inside the organization. That server usually holds more than the owner expects: the full source code, database passwords, the keys that connect you to payment gateways and government services, and the right to deploy to the servers your customers use. Whoever controls it can read all of that, and can change your code before it reaches your customers.

What exactly did GitLab announce?

According to GitLab's official patch release announcement, the flaw sits in the part that processes regular expressions inside build and deployment pipeline settings (CI/CD). A regular expression is a short piece of text that describes a search pattern. The announcement says the flaw could allow an unauthenticated user to execute arbitrary code on the GitLab server through a specially crafted regular expression, due to insufficient validation of those expressions. A researcher reported it through GitLab's bug bounty program on HackerOne.

The announcement does not say the flaw has been exploited. But a score of 10 means it can be exploited over the internet, with no password and no help from any employee. Attackers usually start hunting for flaws like this within days of a fix going public, because the fix itself points to where the weakness is.

What else is in the patch?

The same patch fixes 23 other vulnerabilities, five of them rated high:

• A malicious script injection (XSS) in syntax highlighting, scored 8.7.
• An authorization flaw when creating pipelines, scored 8.5.
• An overly permissive regular expression affecting file access, scored 8.2.
• An authorization flaw in pipeline execution policies in the paid edition, scored 7.7.
• A prompt injection flaw in the GitLab Duo AI agent in the paid edition, scored 7.3.

So versions older than 19.2, which the critical flaw does not affect, are not necessarily safe. GitLab's official maintenance policy says security fixes are backported only to the current release and the previous two monthly releases. A server on anything older no longer receives security fixes at all, and needs an upgrade regardless.

Who needs to act?

• GitLab.com cloud users: nothing to do; GitLab says the service already runs the patched version.
• GitLab Dedicated customers: nothing to do either, according to the announcement.
• Anyone running GitLab on their own server: upgrade immediately. That is GitLab's explicit recommendation for every self-managed installation.
• Anyone unsure where their GitLab runs: ask your team or the vendor that built your systems today. Many in-house servers were set up by a former vendor and then forgotten.

Practical steps for this week

1. Find the version: ask your technical lead to open the Help page in GitLab, read the version number shown there, and compare it with the numbers above.
2. Schedule the upgrade today, not at month end: per GitLab's announcement, a single-node server goes down during the patch until database migrations finish, while multi-node setups can be patched without downtime if the proper zero-downtime procedure is followed. An hour of downtime outside working hours costs far less than a compromised server.
3. If you are on 19.3: go straight to 19.3.5, not 19.3.4. The announcement notes that 19.3.4 had a bug affecting merge request pages when the Ona integration was enabled, fixed in 19.3.5.
4. Reduce internet exposure: if nobody outside the company needs to reach your GitLab server, make it accept connections only from the company network or through a VPN. This does not replace patching, but it narrows the door next time.
5. Check after patching: review recently created users, keys and access tokens. If anything appears that nobody recognizes, rotate the passwords and keys stored on the server.

Upgrade steps for every installation method are in GitLab's official upgrade guide.

The Origami view

We use GitLab every day, since our repositories live there, so we follow its security announcements as closely as our invoices. The lesson is wider than GitLab: every system you run yourself to keep your data in-house comes with the duty to patch it on the day a fix lands. The problem we see most often is not that decision itself but the missing name of whoever is responsible for updates. A server a vendor set up three years ago, which nobody knows who maintains, is the first thing an attacker looks for. We said the same about the Magento store flaw: patching alone is not enough if it comes late. If you need someone to review your servers or take over their updates, get in touch.

Sources

• GitLab: Critical Patch Release 19.4.2, 19.3.5, 19.2.8 and CVE-2026-97229, October 12, 2026
• GitLab: maintenance policy and which releases receive security fixes
• GitLab: upgrade guide for every installation method