GitLab CVSS 10 vulnerability: what “unauthenticated” means depends on who can create projects on your server

If you run a self-managed GitLab instance on the 19.2, 19.3 or 19.4 release branches, plan an update today. On 12 October 2026, GitLab released versions that fix 24 vulnerabilities. One has a CVSS score of 10.0: a specially crafted regular expression in a CI/CD configuration could lead to code execution on the GitLab server.

Headlines said an unauthenticated user could run code on the server. GitLab’s advisory is more cautious. It says this is possible “under certain conditions” but does not specify them. According to The Hack Academy, the exploit path Rapid7 demonstrated depends, among other things, on who can create projects and write CI/CD configurations on your server.

What GitLab says

According to GitLab’s patch advisory, versions 19.4.2, 19.3.5 and 19.2.8 of Community Edition and Enterprise Edition were released on 12 October 2026. GitLab strongly recommends upgrading every self-managed instance to one of these versions immediately. The advisory says GitLab.com is already running a patched version, and GitLab Dedicated customers do not need to take any action.

The main vulnerability is CVE-2026-97229. The advisory describes it as an integer overflow in the CI/CD regular expression compiler. It says that, under certain conditions, the vulnerability could have allowed an unauthenticated user to execute arbitrary code on the GitLab server through a specially crafted regular expression in a CI/CD configuration. The advisory attributes the vulnerability to insufficient validation of regular expressions.

• Affected versions: CE/EE, from 19.2 up to but not including 19.2.8, from 19.3 up to but not including 19.3.5, and from 19.4 up to but not including 19.4.2.
• Severity: Critical, CVSS 10.0. The published vector indicates that the vulnerability can be exploited over the network, with low attack complexity and no privileges or user interaction required.
• Reporter: joaxcar, through GitLab’s bug bounty program on HackerOne.

Other details in the advisory that matter when planning the update:

• 19.3.5, not 19.3.4. According to the advisory, version 19.3.4 had a bug that affected merge request pages when the Ona integration was enabled. The bug was fixed in 19.3.5.
• The other fixes. Besides the critical vulnerability, the advisory lists five High-severity vulnerabilities. These include XSS in syntax highlighting (8.7) and a vulnerability that allows a user with the Developer role to run pipelines on protected branches without authorization (8.5). According to the advisory, three Medium-severity vulnerabilities allow an unauthenticated user to read confidential notes or work item content that should not be visible to them.
• Ruby patches. The bug fix lists for all three versions include regular expression patches for Ruby 3.3 and 3.4. The advisory does not explicitly link them to the CVE.
• Full details in 90 days. Under GitLab’s policy, the issues describing each vulnerability become public 90 days after the release of the version that fixes it.
• Downtime. These releases include database migrations. On a single-server installation, the update will cause downtime because the migrations must finish before GitLab starts. A multi-server installation can be updated without downtime using the zero-downtime process. Version 19.3.5 also includes post-deployment migrations.

The advisory does not offer a temporary workaround.

What “unauthenticated” means in practice

GitLab does not explain what the specific conditions are. According to The Hack Academy, Rapid7 published its own analysis on 13 October. The report says Rapid7 researchers reproduced code execution on the official GitLab 19.4.1 Community Edition image, but the same input did not lead to code execution on the official 19.4.2 image. According to Rapid7, the code ran in the Ruby process as GitLab’s git user.

According to The Hack Academy, the demonstrated exploit path required the attacker to control the CI/CD configuration of a public project, along with other conditions related to the project itself. Rapid7 noted that on a server with open registration where new users can create projects, even a newly registered account is enough to meet this condition. In other words, “unauthenticated” here refers to anyone who can register an account on your server. According to the report, Rapid7 described one exploit path and did not claim there were no others.

For those unable to update immediately, Rapid7 suggested restricting anonymous access to public projects and preventing untrusted users from creating or writing to public projects. According to The Hack Academy, Rapid7 stressed that these measures reduce exposure only to the exploit path it demonstrated. They do not fix the vulnerable compiler.

What the coverage gets wrong

The Hacker News headline. The article is titled “GitLab Patches CVSS 10.0 Flaw That Could Let Unauthenticated Users Run Server Code”. The article body quotes the advisory in full, including the caveat “under certain conditions”, but the headline leaves it out. Someone reading only the headline might conclude that anyone who can reach a vulnerable GitLab server can run code on it, regardless of its settings. GitLab’s advisory does not say that. In Rapid7’s reproduction, the demonstrated exploit path depends on the server’s settings.

The number of High-severity vulnerabilities. The Hacker News article says three High-severity vulnerabilities were fixed alongside the critical vulnerability. GitLab’s table lists five. The two additional vulnerabilities affect Enterprise Edition only: CVE-2026-81839 (scheduled pipeline execution policies, 7.7) and CVE-2026-96893 (content injection into AI agent instructions in Duo Agent Platform, 7.3). If you run EE, you need to account for these as well.

What did not happen

According to The Hack Academy, none of the sources reviewed reported exploitation of CVE-2026-97229 in the wild. Rapid7 wrote that, as of 13 October, there was no confirmed evidence of exploitation in the wild. Cybersecurity Dive reported on 12 October that it was unclear whether attackers had begun exploiting the vulnerability, and that it had not been added to CISA’s KEV catalog as of that morning. These statements apply only to their publication dates. According to The Hack Academy, Rapid7 reproduced the exploit in its lab and did not publish the code.

The reproduction itself has limits. It shows that one exploit path works, not that it is the only one. Until the full details are disclosed, questions remain. According to The Hack Academy, it is not known whether other exploit paths exist, what the full root cause is, or which reliable indicators could reveal exploitation. A CVSS score describes the severity of a vulnerability, not how exposed your server is. Actual exposure depends on who can create projects on the server and whose CI/CD configurations it processes.

Do not confuse this vulnerability with earlier GitLab vulnerabilities. The Hacker News mentions CVE-2026-85706, an earlier vulnerability rated 10.0 that, according to the article, attackers tried to exploit in the wild within hours of disclosure. According to the coverage, this is a different vulnerability, with a different cause and affected version range. What happened after its disclosure tells us nothing about CVE-2026-97229, but it is a reminder of how little time may pass between disclosure and exploitation attempts.

What this means for your server

Update to the appropriate version for your release branch

Update to 19.2.8, 19.3.5 or 19.4.2. On the 19.3 branch, update to 19.3.5, not 19.3.4. If you run a single server, schedule downtime for the migrations. After the update, check that the version actually running is the patched version.

Check who can register and create projects

Based on Rapid7’s reproduction, the key question is whether a stranger can register an account and write a CI/CD configuration in a public project. A server used by an internal team generally has no reason to leave registration open. Check whether registration is open, whether new users can create projects, and who can create public projects. Restrict these options even after updating, because they determine how quickly anyone on the internet could exploit the next CI/CD vulnerability.

If registration was open, check what was created

If registration was open while the server was running a vulnerable version, review recently created accounts and public projects, along with their CI/CD configurations. These are not published indicators of exploitation: according to the reports, such indicators are not yet known. This is a reasonable starting point for a review.

Limit what the GitLab server can reach

According to Rapid7, the code ran as the git user. A GitLab server needs legitimate outbound traffic, for example for repository imports, webhooks and mirrors. Identify the destinations the server actually needs to connect to, and use the firewall to restrict access to other destinations. The same patch release also fixed an SSRF vulnerability in repository imports that, according to the advisory, allowed access to resources on the internal network. This is another reason to isolate the GitLab server from the internal network as much as possible.

How nuDefend helps

nuDefend runs on your Linux server and provides two independent layers of protection. At the network layer, traffic to and from IP addresses known to be malicious is blocked by the kernel firewall. These addresses include botnet command-and-control servers, active scanners and malware infrastructure. At the DNS layer, dangerous domains are disabled system-wide, so no application on the server can resolve or reach them. The threat lists are cryptographically signed and updated automatically.

The dashboard shows a count of blocked outbound traffic. A value above zero may provide an early warning that something on the server tried to contact an external server.

The nudefend expose command shows every service listening on the server and who can reach it, from the server’s own perspective. If a service that was internal-only becomes externally accessible, nuDefend detects the change and alerts you. You can block an exposed port from the dashboard or the command line, after a preview shows exactly what will be blocked. If your GitLab server’s users are in a small number of countries, you can also use country blocking to allow access only from the countries you choose. More details are available in the documentation.

The bottom line

CVE-2026-97229 is rated 10.0, and GitLab recommends updating immediately. Update to 19.2.8, 19.3.5 or 19.4.2. The advisory says exploitation is possible “under certain conditions”. In Rapid7’s reproduction, the demonstrated exploit path requires control over a CI/CD configuration in a public project. According to The Hack Academy, Rapid7 noted that on a server with open registration where new users can create projects, even a newly registered account is enough. After updating, check who can register and create projects on your server, and restrict the destinations the GitLab server can reach.