GitLab has pushed out an unscheduled critical release to fix CVE-2026-97229, a CVSS 10.0 flaw that could let an attacker with no account run code on self-managed GitLab servers. Anyone hosting their own instance should treat this as a same-day upgrade, because it also patches 23 further issues.
What happened
GitLab has shipped versions 19.4.2, 19.3.4 and 19.2.8 of both its Community Edition (CE) and Enterprise Edition (EE). BleepingComputer and Cybersecurity Dive both reported the release on Monday 12 October 2026, though GitLab’s release notes now carry a date of 8 October. Either way, this was an ad-hoc critical release outside the usual second- and fourth-Wednesday schedule, which shows how seriously GitLab rates the bug.
That bug, tracked as CVE-2026-97229, sits in the component that compiles regular expressions used in CI/CD pipeline configuration. GitLab gives it the maximum CVSS 3.1 score of 10.0. Its advisory says that under certain conditions an unauthenticated user could execute arbitrary code on the GitLab server. GitLab “strongly recommend[s]” that all self-managed installations upgrade immediately.
GitLab.com already runs the fixed code, and customers on GitLab Dedicated, the single-tenant managed service, need do nothing. The exposure is the large population of organisations that run GitLab on their own servers or cloud tenancies. The flaw was reported by the researcher known as joaxcar through GitLab’s HackerOne bug bounty programme.
At the time of writing nobody had publicly reported exploitation in the wild. Cybersecurity Dive noted that as of Monday morning the US Cybersecurity and Infrastructure Security Agency (CISA) had not added the CVE to its Known Exploited Vulnerabilities (KEV) catalogue. That should not be read as a reason to wait. Last month, GitLab’s previous maximum-severity bug, the path traversal flaw CVE-2026-85706, was added to KEV the day after it was disclosed.
The technical picture
BleepingComputer reports that GitLab has classified the root cause as an integer overflow (CWE-190) in the CI/CD Regular Expression Compiler. This engine handles the regular expressions in projects’ pipeline configuration files. GitLab puts the problem down to insufficient validation of those expressions. A specially crafted pattern placed in a CI/CD configuration can trigger the overflow and, from there, code execution on the server.
The CVSS vector explains the perfect score. The attack works over the network, has low complexity, needs no privileges and no user interaction, and the scope is marked as changed. In plain terms, the impact can extend beyond the vulnerable component, potentially to the host and whatever the GitLab service can reach. GitLab keeps security issue details private for 90 days after a fix, so little more is public.
Patching the headline bug is not the whole job. The same releases fix 24 vulnerabilities in total: one critical, five high, fourteen medium and four low. The high-severity ones are worth knowing about in their own right:
- CVE-2026-92883 (CVSS 8.7): cross-site scripting in syntax-highlighted output, reachable via a malicious repository.
- CVE-2026-16301 (CVSS 8.5): a user with the Developer role could run pipelines on protected branches without authorisation.
- CVE-2026-14814 (CVSS 8.2): poisoning of cached raw file responses that could expose protected environment variables.
- CVE-2026-81839 (CVSS 7.7, EE only): scheduled pipeline execution policy records survived a project transfer, letting pipelines run with the new group’s privileges.
- CVE-2026-96893 (CVSS 7.3, EE only): manipulation of AI agent instructions leading to unintended command execution.
Affected builds include 19.3 before 19.3.4 and 19.4 before 19.4.2, plus older branches before 19.2.8. BleepingComputer gives the lowest affected branch as 19.2, while GitLab’s current notes say 19.1, so anyone on either should upgrade. The current notes also warn that the patch includes database migrations, which cause downtime on single-node instances.
Why it matters for UK organisations
Self-hosted GitLab is widely used in the UK, and it is often more critical than people assume. Fintechs, banks, government suppliers, universities, defence contractors and software houses all run it in-house, often for data residency or regulatory reasons. In many of these organisations, the GitLab server is the single place that holds source code, pipeline definitions, deployment keys, cloud credentials stored as CI/CD variables and the runners that push code into production.
Code execution on that box is not a contained incident. It is a supply chain problem. An attacker who controls GitLab can read secrets, change code before it ships, tamper with build artefacts and move into whatever environments the runners can reach. For organisations falling under the Cyber Security and Resilience Bill, or supplying firms that do, a compromise of the build system would be very hard to explain to customers or regulators.
There is also a history to consider. BleepingComputer counts five GitLab flaws that CISA has flagged as exploited since November 2021, and ransomware operators used at least one of them.
Expert view
In my experience, GitLab is one of the most underestimated assets on an internal network test. When we test, it is often reachable from the internet so that contractors and remote staff can work. It also commonly holds long-lived tokens with far more privilege than anyone remembers granting. A pre-authentication bug with a changed scope is about as bad as it gets for that kind of system.
The details of this flaw matter too. Regex engines are a classic place for parsing bugs, because they take complex attacker-supplied input and do arithmetic on lengths and repetitions. GitLab has not said how an unauthenticated user gets a crafted pattern into the compiler. My advice is to plan as if public merge requests, sign-up flows or exposed APIs could be the route until the details are known. If your instance allows open registration or public projects, your exposure is probably higher than you think.
I would also not treat the absence of a KEV entry as comfort. Last month’s maximum-severity GitLab flaw was added to KEV about a day after disclosure. Assume the same timeline here.
What to do now
- Upgrade today. Move self-managed CE and EE instances to 19.4.2, 19.3.4 or 19.2.8. Under Cyber Essentials security update management, critical and high-risk fixes must go on within 14 days. For an internet-facing GitLab server, aim for hours, not days.
- Cut exposure while you patch. If you cannot upgrade immediately, restrict access to GitLab at the boundary firewall or reverse proxy so that only VPN or known addresses can reach it. This is the Cyber Essentials firewalls control in practice.
- Close open doors. Turn off public sign-up unless you genuinely need it, and review which projects are public. This fits the secure configuration and user access control themes.
- Check for signs of compromise. Review recent changes to CI/CD configuration files for unusual regular expressions, look for unexpected processes or files on the GitLab host, and check runner activity for jobs nobody recognises.
- Rotate what matters. If an exposed instance ran a vulnerable build, plan to rotate CI/CD variables, deploy tokens, runner registration tokens and cloud keys stored in GitLab.
- Watch KEV and GitLab’s advisories.
Bottom line
CVE-2026-97229 is a maximum-severity, no-login code execution bug in the system that builds and ships your software. GitLab has fixed it on its own platform. Self-managed customers now carry the risk. Patch today, lock down access while you do it, and assume attackers are already studying the fix.
Sources
- GitLab: GitLab Critical Patch Release: 19.4.2, 19.3.4, 19.2.8
- BleepingComputer: GitLab warns of max severity code execution vulnerability
- Cybersecurity Dive: GitLab fixes serious vulnerability that exposed software environments to sabotage
- SecurityOnline: GitLab Critical Vulnerability CVE-2026-97229 Hits CVSS 10
