On October 12, 2026, GitLab released versions 19.4.2, 19.3.5 and 19.2.8 to fix a critical flaw, rated 10 out of 10, that under certain conditions let someone run code on the server without logging in. It affects self-managed GitLab from 19.2 onward. GitLab.com is already patched.
What we know
- What GitLab released: according to its October 12 patch release note, versions 19.4.2, 19.3.5 and 19.2.8 of the Community and Enterprise editions fix 24 security issues: 1 critical, 5 high, 14 medium and 4 low.
- The critical flaw: the same note describes CVE-2026-97229 as an integer overflow in the CI/CD regular expression compiler, the part that reads pipeline rules. GitLab says that, under certain conditions, an unauthenticated user could execute code on the server. It scores 10.0 on the CVSS scale.
- Affected versions: per GitLab, all versions from 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2.
- Who found it: a researcher known as "joaxcar," through GitLab's HackerOne bug bounty program.
- Who does not need to act: GitLab says GitLab.com already runs the patched version and GitLab Dedicated customers do not need to do anything.
- About 19.3.4: the note says that version had a bug on merge request pages when the Ona integration was enabled, fixed in 19.3.5.
- Downtime: the patch includes database migrations. GitLab warns that single-node instances will have downtime during the upgrade, because migrations must finish before GitLab starts. Multi-node setups can upgrade without downtime.
- Attacks: none of the sources checked mention active exploitation. BleepingComputer and The Hacker News reported the release on October 12 and 13.
What changes and what doesn't
If your team keeps its website code on GitLab.com, there is nothing to do for this flaw.
It matters if you run your own GitLab on a server or VPS, a common setup for storing a site's code and deploying it through pipelines. Those instances do not update themselves: someone has to do it.
The other fixes in the release are less severe, but they include several permission issues and a prompt injection issue in the GitLab Duo Agent Platform (Enterprise only, 7.3 out of 10). The same versions fix all of them.
If your GitLab is older than 19.2, the note does not list it as affected by the critical flaw, but it does not ship fixes for those branches either.
How to tell if you are affected
- Check where your GitLab lives. If you sign in at gitlab.com, you are covered. If you use your own address (for example, git.yourcompany.com), keep going.
- Check the version. With an admin account, the version shows in the Admin area and on your instance's Help page (the /help address).
- Pick the target for your branch: 19.4.x → 19.4.2; 19.3.x → 19.3.5, even if you already installed 19.3.4; 19.2.x → 19.2.8.
- Plan the downtime. If GitLab runs on a single server, warn the team: no pushes or deploys during the upgrade. Take a backup first.
- Review your site's deployments. If your GitLab was reachable from the internet on an affected version, check who can create or edit pipelines and consider rotating the deploy secrets stored as CI/CD variables (hosting access, FTP, API keys).
- If someone else runs the server, ask them: "Which GitLab version are we on, and when did we move to 19.4.2, 19.3.5 or 19.2.8?"
Related: GhostAction Returns: Fake GitHub Workflows Steal API Keys
Sources
- GitLab, "GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8," October 12, 2026
- BleepingComputer, "GitLab warns of max severity code execution vulnerability," October 12, 2026
Updates: this article will note it if GitLab or another primary source reports attacks using this flaw.